Basic support for planar configuration

[pka]

Basic implementation for reading images in planar configuration.

Fixes #198.

[fintelia]

This looks good to me. Could you also add handling for tiled planar images? I think it should just be a matter of updating the check at line 272 of src/decoder/image.rs.

[pka]

This looks good to me. Could you also add handling for tiled planar images? I think it should just be a matter of updating the check at line 272 of src/decoder/image.rs.

I don't know how tiled planar images are organized. Are planes/bands row oriented or are they in every nth tile?

[HeroicKatora]

The best I can come up with is: it doesn't specify. https://web.archive.org/web/20210108174645/https://www.adobe.io/content/dam/udp/en/open/standards/tiff/TIFF6.pdf

Planar format. The components are stored in separate “component planes.” The
values in StripOffsets and StripByteCounts are then arranged as a 2-dimensional
array, with SamplesPerPixel rows and StripsPerImage columns. (All of the col-
umns for row 0 are stored first, followed by the columns of row 1, and so on.)
PhotometricInterpretation describes the type of data stored in each component
plane. For example, RGB data is stored with the Red components in one compo-
nent plane, the Green in another, and the Blue in another.

So: we can only recombine planes when PhotometricInterpretation is recognized, and only row-based encoding is mentioned. I can't find anything in imagemagick to indicate particular support for tile based images as well, but then again that decoding loop is somewhat obtuse C code to put it lightly.

[fintelia]

The easiest strategy may be to generate a tiled planar TIFF using gdal_translate and see what the layout is

[HeroicKatora]

This has caused me some headache. It seems improper to return partial data with no indication of it occurring. At that point, wouldn't users simply reach for manual chunk iteration anyways? I've been considering: the library is already choosing a layout for the usual case with no control given to the caller. Couldn't we just decide and document how to handle planar images, too?

[pka]

Alternatively we could return no image, like now. The goal of this PR was extending the Decoder API to support planar-aware reading.

[pka]

The best I can come up with is: it doesn't specify. https://web.archive.org/web/20210108174645/https://www.adobe.io/content/dam/udp/en/open/standards/tiff/TIFF6.pdf

Planar format. The components are stored in separate “component planes.” The
values in StripOffsets and StripByteCounts are then arranged as a 2-dimensional
array, with SamplesPerPixel rows and StripsPerImage columns. (All of the col-
umns for row 0 are stored first, followed by the columns of row 1, and so on.)
PhotometricInterpretation describes the type of data stored in each component
plane. For example, RGB data is stored with the Red components in one compo-
nent plane, the Green in another, and the Blue in another.

So: we can only recombine planes when PhotometricInterpretation is recognized, and only row-based encoding is mentioned. I can't find anything in imagemagick to indicate particular support for tile based images as well, but then again that decoding loop is somewhat obtuse C code to put it lightly.

Looks fine, seems like I was lucky.

[pka]

The easiest strategy may be to generate a tiled planar TIFF using gdal_translate and see what the layout is

We could also ask @rouault for support.

[fintelia]

I finally went and checked what gdal_translate does for tiled images. Turns out it outputs all the tiles for the first band, then all the tiles for the second band, and so on. This matches what the PR assumed, so I think this is set to go ahead and merge.

(Interestingly, gdal chose offsets for tiles that followed a different order: red channel of first tile, blue channel of first channel, etc. This doesn't impact decoding because TIFF has no guarantees on where in the file each chunk is in relation to the others)