It’s my first time posting here so please forgive any faux pas. I re-commented on an issue here but I feel very lost and heard this would be a good place to ask.

It’s not clear to me what SamplesPerPixel in the OMEXML metadata is for - is it per channel or is global? The description from the OMEXML specification is not clear to me: “The number of samples the detector takes to form each pixel value. [units:none]” refers to “pixel” but multiple channels often come together to form a “pixel.”

My example (as in the Github Issue) input is de-interleaved RGB image with three channel: red, green, and blue. But each channel has a SamplesPerPixel of 3 and I wonder if that is throwing the pipeline off, causing it to drop the other two channels when the --rgb flag is on (see the link for more description).

So I guess my question is what SamplesPerPixel should be, and if anyone could point me to some “ground truth” ome-tiff RGB files that I coudl compare against - I have not been able to find any. I’m not expecting a “fix” to the pipeline - that was more just a jumping off point for this question since fixing the input data might fix the odd output of the pipeline.


Hi @ilan-gold, are you generating the input images yourself? The SamplesPerPixel is on a per channel basis but I would almost always expect it be constant throughout.

Unfortunately the set of public OME-TIFF doesn’t include an RGB file, that is something we should probably add in future. However for a de-interleaved RGB image what I would expect to see would be a single Channel with the SamplesPerPixel set to 3. For non RGB this would be 3 separate channels with SamplesPerPixel set to 1.

An example of the de-interleaved RGB image would be:

   <Image ID="Image:0" Name="color.tiff">
      <Pixels BigEndian="true" DimensionOrder="XYCZT" ID="Pixels:0" Interleaved="false" SignificantBits="8" SizeC="3" SizeT="1" SizeX="512" SizeY="512" SizeZ="1" Type="uint8">
         <Channel ID="Channel:0:0" SamplesPerPixel="3">

Looking at your input on the GitHub thread, essentially what happens in the background is that the readers and writers see SizeC = 3 and will be dividing it by SamplesPerPixel = 3 to work with an effective Channel size of 1. So the output will only have the expected single channel and it is most likely that the extra Channels from the input XML are going to be represented as a single channel in the output. Having the input match the sample above (or the output from the GitHub thread) will be the correct expected values.

1 Like

Hello @dgault, I’m going to digest this a bit so might have further questions but this is very helpful. I am not the one generating the images, so I will need to either talk to those generating them or continue onward with my hack. I never noticed the interleaved flag - nifty!