Please tell me the type of SizeC

We are trying to get the metadata from TIF file using the following Bioformats API Method.
-Get sizeC()
I want to know the pattern of SizeC

For example, sizeC = “3” means BGR.
I want to know the pattern for CMY.

getSizeC() doesn’t necessarily mean RGB, or CMY. It could also mean three greyscale image planes. You also need to call getRGBChannelCount(). And you additionally need to call getEffectiveSizeC to be able to distinguish between planar or interleaved RGB data.

The interaction between these three values is not particularly intuitive if you aren’t already familiar with how they all work. The Bio-Formats source code is likely the definitive source of information for how to use them properly.

The existing Bio-Formats API does not allow one to distinguish between RGB, CMY or other non-greyscale interpretation. There is no equivalent to the TIFF PhotometricInterpretation tag.

2 Likes

Sir May I know how to getEffectiveSizeC ?
Bc I read metadata from this file I get SizeC = 3 and when I check RGB mode using pillow I get this image also as RGB when I covert it to png I still get gray image. LiveDead2_Plate_R_p00_0_A03f03d1.TIF (1.3 MB)

Please try this macro

// This macro will open the image in a file with the suffix .TIF and work in batch mode
// Please don't use space in name of the file and the folder
input = getDirectory("choose the input directory"); 
run("Bio-Formats Macro Extensions");
list = getFileList(input);   
for (i=0; i<list.length; i++) {
	if (endsWith(list[i],".TIF")){
		inputPath= input + list[i];
run("Bio-Formats Importer", "open=inputPath color_mode=Default rois_import=[ROI manager] view=Hyperstack stack_order=XYCZT");
imagesName = getTitle();
close("*");
Ext.setId(inputPath);
// Gets the 'effective' number of channels, such that: effectiveSizeC * sizeZ * sizeT == imageCount
Ext.getEffectiveSizeC(effectiveSizeC);
print("effectiveSizeC for : " + imagesName +" is "+ effectiveSizeC);
// Gets the number of focal planes in the dataset
Ext.getSizeC(sizeC);
print("SizeC for : " + imagesName +" is "+ sizeC);
//Gets the number of channels per composite image plane: sizeC / rgbChannelCount == effectiveSizeC
Ext.getRGBChannelCount(rgbChannelCount);
print("rgbChannelCount for : " + imagesName +" is "+ rgbChannelCount);

	}
}
2 Likes

While you likely won’t encounter this in practice, you could potentially have an image with two or more RGB channels. Or one RGB and one or more greyscale channels within a single image plane. In these cases, the assumption that effectiveSizeC = sizeC/rgbChannelCount will be broken. That assumption is made internally by Bio-Formats, and is true for the vast majority of images, but the OME data model can represent more complex images which could potentially break these assumptions. EffectiveSizeC corresponds to SizeC in the Pixels element. SizeC is the sum of the TIFF SamplesPerPixel attributes for each of the channels, so it’s essentially the summed sub channel count.

This is why in OME Files, we made this unambiguous by adding a channel index to getRGBChannelCount to properly represent the storage in the OME data model within the Pixels element. But it doesn’t address the shortcomings at the level of the data model itself.

Bio-Formats has yet to pick up this change as far as I can see, looking at the current IFormatReader.

I should have also mentioned that you need to check the isInterleaved() method (which does have a channel index), to check if the RGB is chunky or planar.

The channel and sub channel abstractions in the reader interface are somewhat complex, and could quite possibly be more user friendly. However, their complexity is representative of the diverse ways that it’s possible to store pixel data even within a single file format (TIFF), not to mention all of the other file formats out there. Ideally, the OME data model should represent the per-channel sample count, planar configuration, photometric interpretation, YCbCr subsampling, compression scheme and image orientation, but only some of these are represented in the API, and others not at all. This presents some difficulty in unambiguously using pixel data obtained through the Bio-Formats API.