clij / clij2-fft

20 stars 6 forks source link

Suppress console output in Python? #18

Closed dpshepherd closed 7 months ago

dpshepherd commented 1 year ago

Hi @bnorthan and @haesleinhuepf -

Thanks for this great library! I am working on testing your excellent RL deconvolution with non-circulant boundary conditions and TV regularization with a microscope post-processing package we have in the lab (part of https://github.com/QI2lab/OPM). The initial results are really encouraging.

We split up the images using Dask because they are so large, which works just fine. However, we get a huge amount of information printed to the console from clij2-fft. Is there a flag to turn off console output for the library?

Thanks! Doug

Edit: also - happy holidays! no rush on this, I was just spending some free time working on this and got carried away. Thanks again!!

bnorthan commented 1 year ago

There is not a flag to turn off the messages yet, but it is simple to add that in (and needed as the diagnostic messages are very intrusive) so I will do so early in the new year. Happy Holidays.

bnorthan commented 1 year ago

I cleaned up the console output massively so now it should only output iteration progress (10,20,30...) on a single line.

I have not yet added an API parameter to turn the detailed output back on (I didn't want to change the API yet), however if you need to debug anything and are able to build the c++ part, you can turn debug output back on by changing this flag https://github.com/clij/clij2-fft/blob/master/native/clij2fft/clij2fft.cpp#L30.

I pushed the new release to the test pypi

Let me know if you have any other issues.

Brian

dpshepherd commented 1 year ago

Pulled and it works great for us! Once our code is cleaned up, we will share in case it is helpful.

Thanks again!

dpshepherd commented 7 months ago

Hi Brian!

Thanks again for all of your work on this.

We just pulled the new pypi version and noticed that the console output is back to being highly verbose. Is there a flag we can set to turn off the output? If not, we're happy to help write a flag to suppress all output if you can point us in the right direction.

The use case here is we still use our own Dask wrapper, not your new one, because we commonly deconvolve skewed data that requires asymmetric padding and tiling. It would be great to have the option to squash all output so that our progress bars stay visible during the computation for big datasets that have many timepoints, stage positions, channels, etc...

Thanks!

bnorthan commented 7 months ago

Do you run on Windows, Linux, or Mac? Or all? Weird thing is that it seemed fine on Linux but the Windows .dll hadn't been rebuilt in a long time. Were you using the pypi-test version, or building the library yourself? I am wondering if the 'concise' version ever made it to pypi-test. Maybe it did and I just messed up when I moved everything to pypi. Whatever the case I just updated the windows .dll, and uploaded to pypi. So now you should get the concise output from the windows pypi version.

I am also working on another update which will allow the user to choose the GPU to run on, which in turn will make it possible to run on multiple GPUs. Since I have to change the API anyway I could also add a 'debuglevel' flag. Considering that you are handling the progress bar yourself would it be useful for you to have absolutely no output? I could have 3 debug levels, verbose, concise (basically only number of iterations updated), and nothing. Long term it would be cool to have a callback update function input, but that's a bigger update to figure out how to get that to work for both Python and Java.

dpshepherd commented 7 months ago

We use both Windows and Linux. This was using a pypi install on Windows, done last week. We can also check the Linux machine.

It would be great to have absolutely no output. We often have collaborators using our instrument(s) who get thrown off by all of the console output.

dpshepherd commented 7 months ago

Updated the Windows machine with 0.25 from pypi and all looks good.

Thanks!