BitsPerSample Being an Array

[ilan-gold]

Hello @constantinius,

I have run into a case where bitsPerSample seems to be an array. At first I thought this should not be allowed but after googling it, it appears to be fair play (http://www.fileformat.info/format/tiff/corion.htm).

--- BitsPerSample
Tag  = 258  (102)
Type = word
N    = SamplesPerPixel
Default = 1

Number of bits per sample. Note that this tag allows a different number of
bits per sample for each sample corresponding to a pixel. For example, RGB
color data could use a different number of bits per sample for each of the
three color planes.

I think without going overboard, we can just be clear that we only support the same bit-depth for each channel - then all we need to do is add a check for an Array here and then take the first value. We can even check to confirm they are all the same value and if not, just exit.

geotiff.js/src/geotiffimage.js

Lines 17 to 57 in 222ea10

	function arrayForType(format, bitsPerSample, size) {
	switch (format) {
	case 1: // unsigned integer data
	switch (bitsPerSample) {
	case 8:
	return new Uint8Array(size);
	case 16:
	return new Uint16Array(size);
	case 32:
	return new Uint32Array(size);
	default:
	break;
	}
	break;
	case 2: // twos complement signed integer data
	switch (bitsPerSample) {
	case 8:
	return new Int8Array(size);
	case 16:
	return new Int16Array(size);
	case 32:
	return new Int32Array(size);
	default:
	break;
	}
	break;
	case 3: // floating point data
	switch (bitsPerSample) {
	case 32:
	return new Float32Array(size);
	case 64:
	return new Float64Array(size);
	default:
	break;
	}
	break;
	default:
	break;
	}
	throw Error('Unsupported data format/bitsPerSample');
	}

[constantinius]

Yes, bitsPerSample is an array, in theory allowing different bit-widths for each channel. I think for many cases, it would be beneficial to use, unfortunately, as I have learned from @rouault, libtiff only supports a single value, thus all software built upon it (like GDAL) does as well.

I know that it complicates the code a bit in some places, but I took the deliberate choice to use an array, that if sometimes the support for this feature is adopted by other software geotiff.js is ready to use it.

For now I think it is best to just use the first value of the array, if you only want a single value.

Is there a particular problem? Otherwise I would close this issue.

[ilan-gold]

I think because the switch expects bitsPerSample to be an integer, this part of the code ends up throwing Error('Unsupported data format/bitsPerSample') if bitsPerSample is an Array. I can make a PR to check for that and use that value.

[constantinius]

Right, but as far as I can see, it is only called with the n-th value or the max of the whole array. Do you have a stack trace?

[ilan-gold]

Ok @constantinius I figured out my issue. It's not bitsPerSample but SampleFormat - I didn't read the error closely enough. You were totally right about the array. The tiff I am dealing with has 3 bitsPerSample but only 1 sampleFormat.

In this portion, we take sampled value of SampleFormat:

geotiff.js/src/geotiffimage.js

Lines 225 to 230 in 222ea10

	getArrayForSample(sampleIndex, size) {
	const format = this.fileDirectory.SampleFormat
	? this.fileDirectory.SampleFormat[sampleIndex] : 1;
	const bitsPerSample = this.fileDirectory.BitsPerSample[sampleIndex];
	return arrayForType(format, bitsPerSample, size);
	}

But in this portion we do what you were referring to with the max of SampleFormat:

geotiff.js/src/geotiffimage.js

Lines 449 to 451 in 222ea10

	const format = this.fileDirectory.SampleFormat
	? Math.max.apply(null, this.fileDirectory.SampleFormat) : 1;
	const bitsPerSample = Math.max.apply(null, this.fileDirectory.BitsPerSample);

So when the first chunk is called, and it looks for the n > 1 SampleFormat, it fails because format is then undefined. Should we standardize these use cases to use max?

[ilan-gold]

P.S This also appears on

geotiff.js/src/geotiffimage.js

Lines 180 to 183 in 222ea10

	getReaderForSample(sampleIndex) {
	const format = this.fileDirectory.SampleFormat
	? this.fileDirectory.SampleFormat[sampleIndex] : 1;
	const bitsPerSample = this.fileDirectory.BitsPerSample[sampleIndex];

. I can make a PR to handle this.

[constantinius]

That would be lovely, thanks

[constantinius]

@ilan-gold

Sorry, this kind of got swept under the rug. What is the status on this?

btw: reading up on SampleFormat: the current implementation is actually correct according to the standard: i.e the format must either be supplied for all bands or 1 (uint) is assumed.

[ilan-gold]

I am fine with closing this then. We were being bombarded with tiff files when I wrote this so honestly, I couldn't reproduce this even if I wanted to. If I run into this again, I'll re-open with a reproducible example (all the data was private when I first opened this).

[constantinius]

Alright, thanks!

[jeffpeck10x]

Re-opening this thread....

I am running into this same issue with interleaved OME-TIFF images produced by qupath, where SampleFormat has length of 1 while BitsPerSample has a length of 3. They are also unfortunately private so I cannot share as examples, but it seems to be all images that we have encountered so far with Creator="OME Bio-Formats 6.11.1" in the OME-XML.

If I inject this before the images are used:

image.fileDirectory.SampleFormat = new Uint16Array([1, 1, 1]);

the problem goes away. I am not sure if the issue is that the TIFFs are incorrect, but they are readable in FIJI, qupath, and Python/tiffile. It is only geotiff.js+viv that is having trouble with them.

From what I can tell, changing this:

  getReaderForSample(sampleIndex) {
    const format = this.fileDirectory.SampleFormat
      ? this.fileDirectory.SampleFormat[sampleIndex] : 1;

to this:

  getReaderForSample(sampleIndex) {
    const format = this.fileDirectory.SampleFormat && this.fileDirectory.SampleFormat[sampleIndex]
      ? this.fileDirectory.SampleFormat[sampleIndex] : 1;

fixes the problem. I am not sure however if this is merely a bandaid and the actual problem is the tiff's themselves.

For reference, I will part of the OME XML below:

<?xml version="1.0" encoding="UTF-8" standalone="no"?>
<!-- Warning: this comment is an OME-XML metadata block, which contains crucial dimensional parameters and other important metadata. Please edit cautiously (if at all), and back up the original data before doing so. For more information, see the OME-TIFF web site: https://docs.openmicroscopy.org/latest/ome-model/ome-tiff/. -->
<OME
    xmlns="http://www.openmicroscopy.org/Schemas/OME/2016-06"
    xmlns:xsi="http://www.w3.org/2001/XMLSchema-instance" Creator="OME Bio-Formats 6.11.1" UUID="urn:uuid:f60e1a3f-4569-49da-aacf-e05f92a2ad4f" xsi:schemaLocation="http://www.openmicroscopy.org/Schemas/OME/2016-06 http://www.openmicroscopy.org/Schemas/OME/2016-06/ome.xsd">
    <Image ID="Image:0">
        <Pixels BigEndian="true" DimensionOrder="XYCZT" ID="Pixels:0" Interleaved="true" PhysicalSizeX="0.4985" PhysicalSizeXUnit="µm" PhysicalSizeY="0.4985" PhysicalSizeYUnit="µm" SizeC="3" SizeT="1" SizeX="28789" SizeY="24984" SizeZ="1" Type="uint8">
            <Channel ID="Channel:0" SamplesPerPixel="3">
                <LightPath/>
            </Channel>
            <TiffData FirstC="0" FirstT="0" FirstZ="0" IFD="0" PlaneCount="1">
                <UUID FileName="test.ome.tif">urn:uuid:f60e1a3f-4569-49da-aacf-e05f92a2ad4f</UUID>
            </TiffData>
        </Pixels>
    </Image>
</OME>

Please advise if you think this should be simply patched in geotiff.js, or if the problem is the TIFF files themselves. Thanks!

[ilan-gold]

@jeffpeck10x @constantinius seemed to say that this is actually not correct for tiff files: #159 (comment). But looking at the specification, I am not so sure: https://www.awaresystems.be/imaging/tiff/tifftags/sampleformat.html. I would be happy to take a PR here, but I don't maintain this repo. Hopefully my review would speed things up though.

[constantinius]

@jeffpeck10x

This seems to be an issue with the TIFF files themselves. SampleFormat and BitsPerSample must be of the same length, exactly the same length as SamplesPerPixel dictates.

Does GDAL open these images?

@rouault how does libtiff deal with malformed images like this?

[ilan-gold]

Ah @constantinius is right, assuming that the N in the above specification document should be identical between two different tags: https://www.awaresystems.be/imaging/tiff/tifftags/bitspersample.html and https://www.awaresystems.be/imaging/tiff/tifftags/sampleformat.html