Deskew-only on py36 won't work

[linshaova]

I'm using version 0.3.8 with py36 on Windows. From the GUI, if I un-check "Do Deconvolution" and check "Save Deskewed", the command window would just pop up error message "Error in subprocess: CudaDeconv" and nothing happens.

The same version on py27 does not have the same issue.

[tlambert03]

hmm... anything in the log window of LLSpy?

[linshaova]

Somehow there isn't a log window open, unlike in previous version.

[tlambert03]

alright... i'll need to get my windows environment set up again to test it, i'll get back to you

[linshaova]

Interestingly "Preview" works for deskew-only.

[tlambert03]

that is interesting, and thanks for noting it. I'm in the middle of 3 different deadline-approaching things at the moment, and because this will require a little bit of setup for me to test, it will probably be at least a week or so before I can get to this. Definitely keep me updated if you figure out anything else though, or if you can get a more informative stack trace anywhere.

[tlambert03]

Also, for what it’s worth: preview uses the shared library function and process calls the binary in a subprocess

[tlambert03]

question: is your py27 version run from a different conda environment? and does that conda environment perhaps have a different cudaDeconv binary (like, have you replaced the binary with your own at any point?). if you do have two different environments (one for py27 and one for py36) can you run the help command for each environment: ~/anaconda-or-miniconda/envs/[name_of_your_env]/bin/cudaDeconv -h

I'm currently working on bringing the llspy interface back up to date with cudaDeconv and the libcudaDeconv shared library... and I suspect that code drift is causing at least some of these recent problems.

[linshaova]

See below for the -h output of the two envs I have. I can see lots of differences. Notably there is a -m [--rMIP] flag in the py27 version but not in the py36 version. I did try again without the "save MIPs" checked in the py36 GUI, but still got the same error and no output.

The following is from py27 env: --drdata arg (=0.104000002) Image x-y pixel size (um) -z [ --dzdata ] arg (=0.25) Image z step (um) --drpsf arg (=0.104000002) PSF x-y pixel size (um) -Z [ --dzpsf ] arg (=0.100000001) PSF z step (um) -l [ --wavelength ] arg (=0.524999976) Emission wavelength (um) -W [ --wiener ] arg (=-1) Wiener constant (regularization factor); if this value is postive then do Wiener filter instead of R-L -b [ --background ] arg (=90) User-supplied background -e [ --napodize ] arg (=15) # of pixels to soften edge with -E [ --nzblend ] arg (=0) # of top and bottom sections to blend in to reduce axial ringing -n [ --NA ] arg (=1.20000005) Numerical aperture -i [ --RL ] arg (=10) Run Richardson-Lucy, and set how many iterations -D [ --deskew ] arg (=0) Deskew angle; if not 0.0 then perform deskewing before deconv -w [ --width ] arg (=0) If deskewed, the output image's width -x [ --shift ] arg (=0) If deskewed, the output image's extra shift in X (positive->left -R [ --rotate ] arg (=0) Rotation angle; if not 0.0 then perform rotation around y axis after deconv -S [ --saveDeskewedRaw ] Save deskewed raw data to files -C [ --crop ] arg Crop final image size to [x1:x2, y1:y2, z1:z2]; takes 6 integers separated by space: x1 x2 y1 y2 z1 z2; -M [ --MIP ] arg Save max-intensity projection along x, y, or z axis; takes 3 binary numbers separated by space: 0 0 1 -m [ --rMIP ] arg Save max-intensity projection of raw deskewed data along x, y, or z axis; takes 3 binary numbers separated by space: 0 0 1 -u [ --uint16 ] Save result in uint16 format; should be used only if no actual decon is performed -p [ --bleachCorrection ] Apply bleach correction when running multiple images in a single batch --input-dir arg Folder of input images --otf-file arg OTF file --filename-pattern arg File name pattern to find input images to process -a [ --DoNotAdjustResForFFT ] Don't change data resolution size. Otherwise data is cropped to perform faster, more memory efficient FFT: size factorable into 2,3,5,7) -G [ --GPUdevice ] arg (=0) Index of GPU device to use (0=first device) -q [ --quiet ] suppress output -v [ --verbose ] verbose output -Q [ --DevQuery ] Show info and indices of available GPUs -h [ --help ] This help message.

And the following is from py36 env: `Created at Howard Hughes Medical Institute Janelia Research Campus. Copyright 20

17. All rights reserved. --drdata arg (=0.104000002) Image x-y pixel size (um) -z [ --dzdata ] arg (=0.25) Image z step (um) --drpsf arg (=0.104000002) PSF x-y pixel size (um) -Z [ --dzpsf ] arg (=0.100000001) PSF z step (um) -l [ --wavelength ] arg (=0.524999976) Emission wavelength (um) -W [ --wiener ] arg (=-1) Wiener constant (regularization factor); if this value is postive then do Wiener filter instead of R-L -b [ --background ] arg (=90) User-supplied background -e [ --napodize ] arg (=15) # of pixels to soften edge with -E [ --nzblend ] arg (=0) # of top and bottom sections to blend in to reduce axial ringing -d [ --dupRevStack ] Duplicate reversed stack prior to decon to reduce Z ringing -n [ --NA ] arg (=1.20000005) Numerical aperture -i [ --RL ] arg (=15) Run Richardson-Lucy, and set how many iterations -D [ --deskew ] arg (=0) Deskew angle; if not 0.0 then perform deskewing before deconv --padval arg (=0) Value to pad image with when deskewing -w [ --width ] arg (=0) If deskewed, the output image's width -x [ --shift ] arg (=0) If deskewed, the output image's extra shift in X (positive->left -R [ --rotate ] arg (=0) Rotation angle; if not 0.0 then perform rotation around y axis after deconv -S [ --saveDeskewedRaw ] Save deskewed raw data to files -C [ --crop ] arg Crop final image size to [x1:x2, y1:y2, z1:z2]; takes 6 integers separated by space: x1 x2 y1 y2 z1 z2; -M [ --MIP ] arg Save max-intensity projection along x, y, or z axis; takes 3 binary numbers separated by space: 0 0 1 -u [ --uint16 ] Save result in uint16 format; should be used only if no actual decon is performed --input-dir arg Folder of input images --otf-file arg OTF file --filename-pattern arg File name pattern to find input images to process -a [ --DoNotAdjustResForFFT ] Don't change data resolution size. Otherwise data is cropped to perform faster, more memory efficient FFT: size factorable into 2,3,5,7) --Pad arg (=0) Pad the image data with mirrored values to avoid edge artifacts. Currently only enabled when rotate and deskew are zero. --LSC arg Lightsheet correction file --FlatStart Start the RL from a guess that is a flat image filled with the median image value. This may supress noise. -p [ --bleachCorrection ] Apply bleach correction when running multiple images in a single batch --skip arg (=0) Skip the first 'skip' number of files. --no_overwrite Don't reprocess files that are already deconvolved (i.e. exist in the GPUdecon folder). -Q [ --DevQuery ] Show info and indices of available GPUs -h [ --help ] This help message.`

[tlambert03]

great, that answers it then... you've got an updated/mismatched cudaDeconv binary in your py36 environment.

to be clear: it is not safe to assume that you can drop in any cudaDeconv binary and have it work well with LLSpy.

LLSpy is, for better or worse, more than just a wrapper around cudaDeconv. It depends on my modified version LLSpy. This is particularly true for the "preview" function, where the binary itself is not being used, but rather the shared library functions are being used. There were a couple bugs in the shared library interface for the original cudaDeconv package that are fixed in my version, and also I've added a lot of things to my cudaDeconv versions that LLSpy assumes are present.

I definitely agree that it would be nice to have complete decoupling (so that, for instance, we could easily drop in the improvements you make to cudaDeconv) ... but unfortunately, the way it's currently coded (which, admittedly, is a mess), LLSpy makes many assumptions about the cudaDeconv library and binary. anyone using newer releases of cudaDeconv is likely to run into issues.

I'm working this week on bringing these things back into sync with each other, and i'm sorry it's been slow... but that's the reason

[linshaova]

Thank you and no rush! I probably won't need the feature for the foreseeable future.

Maybe both cudaDeconv and LLSpy should be coded to be based on DLL/DSO, which I can definitely help.

[tlambert03]

definitely should be, and that was the goal of LLSpy2... and I made it quite a ways, but then the real world kicked in, and tying up all the little loose ends that would make it useable by anyone besides me started taking more time than I had to give it. so at the moment I'm just trying to patch the many little holes in the older version so that it is at least still useable.

[tlambert03]

should be resolved in 0.4.0