Issues in exported BLO file

[din14970]

• The dimensions of the exported blo file seem to be completely wrong in units of cm. Dimensions in the hspy file are correct
• The checkbox rescale to 8-bit doesn't seem to do anything for blo - in either case data is exported as 8-bit data. Does blo support 16-bit?

[harripj]

On the second point, .blo doesn't currently support 16-bit, but we may want to be careful how we convert down to 8-bit. As far as I understood normalize_convert will do some clipping if required and then rescale over the full data range (0-255 for 8-bit .blo) for each image. This will mean that relative intensities between images are somewhat lost. If the rescale checkbox is unchecked then there skimage.util.img_as_ubyte will also convert to 8-bit, but the maximum 8-bit value 255 will only be written if the 16-bit value is within the top 256 16-bit levels ((2**16-1)-256 upwards). I think for virtual reconstructions it is useful to maintain some relative order in the intensity scale between frames (so as to not artificially brighten certain pixels).

Here is an example:

[din14970]

very good points, when I was implementing this I only thought of using the full range of 0-255 to have a minimum loss of intensity resolution, which I guess should be fine for indexing, but indeed relative intensities between images is important for VBF/VDF. Should the user have a choice in which way to do it?

On the other hand, when you linscale the image (which you would most likely do when converting to 8-bit, since 2**16 is almost never reached in the raw images - the raw images are very dim), both conversion methods should be identical, as the linscaled images use the full range.

I guess the main point is that the checkbox "use 8-bit" is a bit confusing, especially when unchecked blo still exports as 8-bit.

[harripj]

Yes rescaling is certainly better for indexing, but not ideal for the reconstructions. So at the moment, I need two files, one rescaled and one not, for my analysis 😅. I'm sure there is a better way but this is fine for now.

I agree that the '8-bit' box is confusing, especially as it is irrelevant for .hspy too. Maybe it should be changed, or at least renamed.

[din14970]

This is exactly the problem with 8-bit datasets and why I'm trying to get ASTAR-like indexing into Pyxem with even more fine-grained user control. I'm quite close to a solution. Pyxem builds on hyperspy, and in this way you would be directly able to index the 16-bit dataset.

[din14970]

then you can do ALL your analysis with python and without compromising on the data