Closed melissalinkert closed 1 year ago
I believe the display differences between the original and converted data are actually due to a bug in MinMaxCalculator
, not a difference in the actual stored pixel values.
I could confirm that showinf -autoscale -fast
on the original and converted data showed different images. The simple test code in https://gist.github.com/melissalinkert/5295a1237b93f52e88c324ddb89f3e5a shows that the pixel values between the two files are the same, as are the scaled pixel values when fixed min/max values are used for scaling. Inspecting the min/max values returned by MinMaxCalculator
showed an unexpected difference though.
showinf -autoscale -fast
with the changes in https://github.com/ome/bioformats/pull/3915 should show the same thing for both original and converted OME-TIFF files here.
Confirmed that the incorrect multi RGB channels rendering was fully related to the Bio-Formats utility issue. With the fix mentioned in https://github.com/ome/bioformats/pull/3915, the image now renders as the original.
For the multi-Z RGB image however, I think there is still a problem with the converted as the planes are written according in XYZCT order. The intermediate Zarr file displays correctly e.g. when opened in napari
.
I think f532408 fixes the multi-Z + RGB case, so this is ready for review again.
Attempts to address #43, as discussed briefly with @sbesson. This still requires that the input channel count be a multiple of 3, as channel merging happens in groups of 3. As noted in the comments, this is maybe something we could consider making configurable as a next step.
More than one timepoint and/or Z section should be supported, along with channel counts greater than 3 (but still a multiple of 3). I tested with 12 channel Zeiss ZVI data (
curated/zeiss-zvi/cecilia/*.zvi
) and various RGB Z stacks/timelapse movies (e.g. some ofcurated/apng/samples/
,curated/zeiss-czi/qa-17173
).