When using a Merger node to create an XYZC image and then trying to write the image using an Image Writer, the resulting files are save with wrong dimension order, i.e. the pixel values end up in the wrong place.
For example, a 2-channel image will contain the data of the second original channel in the second half of the z stack, spread across both channels (when re-opened using an Image Reader, or in Fiji).
Here's an example workflow to reproduce the issue (look at the images written to disk):
In our "real-world" use case, the order of dimensions differed depending on the image format: in TIF, dimensions were interleaved/mixed up between Z and Channel, but when saving to ICS, the data was interleave line-wise in the Y dimension. Whereas the former is easy to work around in Fiji by Hyperstack To Stack and Stack To Hyperstack, the latter issue is more difficult to handle.
A work-around I didn't test yet would be to use the Dimension Swapper and Set Image Metadata, but I guess that wouldn't actually fix the pixel order, would it?
When using a Merger node to create an XYZC image and then trying to write the image using an Image Writer, the resulting files are save with wrong dimension order, i.e. the pixel values end up in the wrong place.
For example, a 2-channel image will contain the data of the second original channel in the second half of the z stack, spread across both channels (when re-opened using an Image Reader, or in Fiji).
Here's an example workflow to reproduce the issue (look at the images written to disk):
Image Writer Dimensions Issue.zip
In our "real-world" use case, the order of dimensions differed depending on the image format: in TIF, dimensions were interleaved/mixed up between Z and Channel, but when saving to ICS, the data was interleave line-wise in the Y dimension. Whereas the former is easy to work around in Fiji by Hyperstack To Stack and Stack To Hyperstack, the latter issue is more difficult to handle.
A work-around I didn't test yet would be to use the Dimension Swapper and Set Image Metadata, but I guess that wouldn't actually fix the pixel order, would it?