Remove 8 bit -> 16 bits conversion

[NicoKiaru]

See bigdataviewer/bigvolumeviewer-core#26

[ekatrukha]

Hello @NicoKiaru

thanks a lot!

While we are at it, can you please check this part, where you load BioFormats?

As I see it, right now the default channel range is always [0 255],
regardless of the datatype. But it looks like we already kind of know what type it is (in this.t).
Maybe you can adjust it automatically?

Now it is a bit annoying, since after loading of 16-bit images one needs to adjust a contrast.

Cheers,
Eugene

[NicoKiaru]

You mean doing an autoscale based on the data or based on the pixel type ?

Fixed value based on pixel type

255 has the advantage to show something in most cases when you open a 16 bit with low signal. Ok, you need to change the scale, but at least there's a good chance you notice that some data is there.

One could put 255 for 8 bits and 65535 for 16 bits (or 32765 is it's signed...). But then again some camera are 12 bits and that makes a very dim brightness. One could think of putting 2048 or whatever as the default for 16 bits, but it's very arbitrary.

Also this means adding some more code.

Autoscaling based on data

It's a whole can of worms... it's generally very difficult and not very robust to big data. If you read just a tiny amount of data (middle plane, low resolution, etc.) you risk to miss relevant data. But if you open many images just reading a bit of data per image can take a long time. FYI there's an autoadjuster in bdv-playground: https://github.com/bigdataviewer/bigdataviewer-playground/blob/master/src/main/java/sc/fiji/bdvpg/sourceandconverter/display/BrightnessAutoAdjuster.java

Reading min max from Bio-Formats

Another thing I wonder is if there is some information stored that bio-formats could read regarding the saved min max display settings. Then I could apply it if it exists, but I'm not sure it is the case.

[ekatrukha]

I see your point about default values and agree with it.
For the stored min max in Bioformats I am also not sure, I think it is too diverse across formats.

[NicoKiaru]

For the stored min max in Bioformats I am also not sure, I think it is too diverse across formats.

There's a IMinMaxStore, but I don't see any "mirror" IMinMaxRetrieve interface:

https://github.com/ome/bioformats/blob/develop/components/formats-api/src/loci/formats/meta/IMinMaxStore.java

[NicoKiaru]

@melissalinkert @sbesson, sorry to bother, but is there a way to retrieve a 'good' min max value without reading data in the bio-formats API ? I see that there's a place to store min max values (https://github.com/ome/bioformats/blob/develop/components/formats-api/src/loci/formats/meta/IMinMaxStore.java) but I don't see if there's any way to read this data back. (Moreover, maybe this metadata is not heavily present in various reader ?)

[melissalinkert]

IMinMaxStore is very rarely populated by individual readers - mostly it's populated by the MinMaxCalculator class, which needs to read data in order to get the actual min/max pixel values. MinMaxCalculator does have methods for retrieving the calculated min and max values, but if reading all of the data isn't possible then that likely doesn't help.

If you haven't already, one thing you might consider is making use of the getBitsPerPixel() method in IFormatReader (https://github.com/ome/bioformats/blob/develop/components/formats-api/src/loci/formats/IFormatReader.java#L123), which corresponds to the SignificantBits value in the OME schema (https://www.openmicroscopy.org/Schemas/Documentation/Generated/OME-2016-06/ome_xsd.html#Pixels_SignificantBits). That isn't a precise min/max, but is more commonly set by various readers, and can help with the 12 bit camera case in particular.

[NicoKiaru]

Ah, nice, then I'll probably use this getBitsPerPixel()!