search

PreibischLab / BigStitcher

ImgLib2/BDV implementation of Stitching for large datasets
GNU General Public License v2.0
64 stars 14 forks source link

BigDataViewer bug #95

Closed pawlowska closed 3 years ago

pawlowska commented 3 years ago

There is a bug in BigDataViewer that I only see if I call BigDataViewer FROM BigStitcher, not when I start it as independent plugin: in Settings->brightness and color, the sliders and the numeric input for min and max are not synced: slider doesn't move when I change the numeric input and vice versa. This is super annoying when trying to see details of cleared samples with large dynamic range of signal.

Does BigStitcher use an old version of BigDataViewer?

StephanPreibisch commented 3 years ago

Hi @pawlowska, I already filed an issue for that behavior (I will link this issue there as well). Nevertheless, this dialog is outdated and you should use the new, much more beautiful one instead :)

Screen Shot 2021-05-06 at 7 58 07 AM Screen Shot 2021-05-06 at 7 58 10 AM
pawlowska commented 3 years ago

@StephanPreibisch I use the update site for BigStitcher and update regularly, under Windows 10, and for me it looks like this: image

StephanPreibisch commented 3 years ago

Please try to not use the old dialog (here on top). Instead go to the right side of the BigDataViewer window and use the new dialog as I tried to outline in my screenshots. Does that work? I am not sure what exactly the problem is?

pawlowska commented 3 years ago

@StephanPreibisch okay, now I see - I need to click on this arrow thingy on the image to open the dialog. There indeed the slider works. Next question: would it be possible to incorporate some sort of "auto" button there, similar to the one in the B&C dialog in Fiji?

StephanPreibisch commented 3 years ago

Yes, but this is more BigDataViewer-related than BigStitcher related. The problem is that in order to do that you need to access pixels which is eventually very expensive, especially for large datasets. BigDataViewer knows which pixels it has accessed in order to render the current view, so it should be based on that I think. Btw, this is so easy in ImageJ as all pixels are always in memory (it is actually getting very slow if the image plane is very big). But we should add that, I totally agree.

StephanPreibisch commented 3 years ago

I added an issue for that as well in BigDataViewer (https://github.com/bigdataviewer/bigdataviewer-core/issues/123), is it OK to close this issue for now?

pawlowska commented 3 years ago

@StephanPreibisch sure, thanks for your help. I don't expect this auto function to be super precise - just as you said, based on pixels that are currently used on the display would be good enough for me.