-
Notifications
You must be signed in to change notification settings - Fork 248
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
bfsave: use the metadata endianness to create the byte array #4261
Conversation
The existing code assumes the data are ordered using big-endian as in the default minimal OME-XML metadata. This adjusts the code to handle OME metadata specifying little-endian ordering
This pull request has been mentioned on Image.sc Forum. There might be relevant details there: https://forum.image.sc/t/issues-with-bfsave-and-native-ome-metadata/106195/4 |
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Tested on matlab.mathworks.com with synthetic data in several pixel types and both little/big endian:
>> data = bfopen('test&pixelType=float.fake')
Reading series #1
.
data =
1x4 cell array
{1x2 cell} {0 java.util.Hashtable} {1x1 cell} {1x1 loci.formats.ome.OMEPyramidStore}
>> bfsave(cat(3, data{1}{:1}), 'float-little.ome.tiff', 'metadata', data{4});
bfsave(cat(3, data{1}{:1}), 'float-little.ome.tiff', 'metadata', data{4});
↑
Invalid expression. Check for missing multiplication operator, missing or unbalanced delimiters, or other syntax error. To construct matrices, use brackets instead of parentheses.
>> bfsave(cat(3, data{1}{:,1}), 'float-little.ome.tiff', 'metadata', data{4});
>> data = bfopen('test&pixelType=float&little=false.fake')
Reading series #1
.
data =
1x4 cell array
{1x2 cell} {0 java.util.Hashtable} {1x1 cell} {1x1 loci.formats.ome.OMEPyramidStore}
>> bfsave(cat(3, data{1}{:,1}), 'float-big.ome.tiff', 'metadata', data{4});
>> data = bfopen('test&pixelType=int32.fake')
Reading series #1
.
data =
1x4 cell array
{1x2 cell} {0 java.util.Hashtable} {1x1 cell} {1x1 loci.formats.ome.OMEPyramidStore}
>> bfsave(cat(3, data{1}{:,1}), 'int32-little.ome.tiff', 'metadata', data{4});
>> data = bfopen('test&pixelType=int32&little=false.fake')
Reading series #1
.
data =
1x4 cell array
{1x2 cell} {0 java.util.Hashtable} {1x1 cell} {1x1 loci.formats.ome.OMEPyramidStore}
>> bfsave(cat(3, data{1}{:,1}), 'int32-big.ome.tiff', 'metadata', data{4});
>> data = bfopen('test&pixelType=uint16.fake')
Reading series #1
.
data =
1x4 cell array
{1x2 cell} {0 java.util.Hashtable} {1x1 cell} {1x1 loci.formats.ome.OMEPyramidStore}
>> bfsave(cat(3, data{1}{:,1}), 'uint16-little.ome.tiff', 'metadata', data{4});
>> data = bfopen('test&pixelType=uint16&little=false.fake')
Reading series #1
.
data =
1x4 cell array
{1x2 cell} {0 java.util.Hashtable} {1x1 cell} {1x1 loci.formats.ome.OMEPyramidStore}
>> bfsave(cat(3, data{1}{:,1}), 'uint16-big.ome.tiff', 'metadata', data{4});
>> data = bfopen('test&pixelType=uint8.fake')
Reading series #1
.
data =
1x4 cell array
{1x2 cell} {0 java.util.Hashtable} {1x1 cell} {1x1 loci.formats.ome.OMEPyramidStore}
>> bfsave(cat(3, data{1}{:,1}), 'uint8-little.ome.tiff', 'metadata', data{4});
>> data = bfopen('test&pixelType=uint8&little=false.fake')
Reading series #1
.
data =
1x4 [cell](matlab:helpPopup('cell')) array
{1x2 cell} {0 java.util.Hashtable} {1x1 cell} {1x1 loci.formats.ome.OMEPyramidStore}
>> bfsave(cat(3, data{1}{:,1}), 'uint8-big.ome.tiff', 'metadata', data{4});
Output .ome.tiff files all look as expected and have correct pixel type/endianness.
Will plan to merge this tomorrow if builds continue to pass overnight. |
https://merge-ci.openmicroscopy.org/jenkins/job/BIOFORMATS-test-repo/296/ now passing with this included. |
See https://forum.image.sc/t/issues-with-bfsave-and-native-ome-metadata/106195
The existing code assumes the data are ordered using big-endian as in the default minimal OME-XML metadata.
This adjusts the code to handle OME metadata specifying little-endian ordering
Testing can be done by downloading the LSM file uploaded https://zenodo.org/records/14510432 at running the minimal code (https://matlab.mathworks.com/ might be
Without this PR, the OME-TIFF should appear corrupted. With this PR included, the array ordering should match the metadata and the output of
showinf 10-01.lsm
should matchshowinf 10-01.ome.tiff
.Additional tests should probably be performed e.g. using synthetic sample files with different endianness and pixel types to ensure that the logic works in all scenarios.