Support multi-sized (e.g. pyramid) TIFFs

[Christoph-Wagner]

Currently, TIFFs with multiple frame sizes are not supported:

foreach (ImageFrame<TPixel> frame in frames)
{
    if (frame.Size() != root.Size())
    {
        TiffThrowHelper.ThrowNotSupported("Images with different sizes are not supported");
    }
}

There is a TODO comment: // TODO: Tiff frames can have different sizes but @JimBobSquarePants asked me to create a feature request as reminder ;)

[antonfirsov]

ImageSharp has a core architectural assumption that an image has a single size (even when it consists of multiple frames), so this won't be easy to achieve.

We can pick the biggest frame, and extend the rest, but I think this is not what users want, since it would loose information.

The only solution I can think of is a custom, TIFF-specific API, that would return an Image<T>[] containing a separate Image<T> for each frame. Any better ideas?

[Christoph-Wagner]

@brianpopow
SKC1H3.zip

Not sure if it’s relevant, but the image is created with the following Magick.NET (ImageMagick wrapper) options:

image.Format = MagickFormat.Ptif;
image.SetAttribute("define", "tiff:tile-geometry=256x256 tiff:ignore-layers");

[brianpopow]

I have checked the example image: tiff format does not provide offset info as gif or animated webp. The example is a typical mipmap image/texture: The first image is the biggest, the second is half the size and so on. I could not find any specifics in the spec, that the first has to be the largest (probably will be, but I guess its not for sure).

One simple solution would be to make all images the same size as the biggest and decode smaller onces at position (0, 0), while leaving the rest of the image as is. We need to decide then howto treat the undefined pixels (should they be black, white, transparent, etc.)

Until we decide howto deal with images of different sizes, a easy solution for this would be to introduce a TiffDecoderOption similar to the GifDecoderOption: FrameDecodingMode, allowing to decode the first frame only. Then the user could manually resize the other mipmap textures from the first one.

[JimBobSquarePants]

That sounds like a plan to me @brianpopow Nice!

[brianpopow]

With #2013 merged to main, the Tiff Decoder now has an option FrameDecodingMode to only decode the first frame or all.

[JimBobSquarePants]

I've made a start on supporting multi-size Tiff files with #2788

Decoding works well, we simply pin the pixel data to the top/left of a frame matching the root frame dimensions.

I just need to put some thought to handling efficient re-encoding so that we do not encode all that dead space.

[JimBobSquarePants]

According to the following information Tiff supports X/Y position tags for the image.
https://awaresystems.be/imaging/tiff/tifftags/search.html?q=position&Submit=Find+Tags

Code		Name	Short description
Dec	Hex
286	0x011E	XPosition	X position of the image.
287	0x011F	YPosition	Y position of the image.

According to the TIFF 6 spec, they are in resolution units. so to work out the pixel position they would be multiplied by X/YResolution and rounded to the nearest int.

I have found nothing to confirm this but I don't think any frames that follow the first frame can be larger than the first frame so we can always take that frame as the image size. We can check X/Y Position for subsequent frames that are smaller and offset them in the buffer like we do during Gif decode.

When encoding we can either allow setting a background color and trimming that or simply trim transparent like I do with Gif in #2455 and set those tags appropriately.

[boukenka]

Any update on this proposition ?

[JimBobSquarePants]

PRs are welcome. If there was an update it would be documented.

[JimBobSquarePants]

Turns out that those tags are for the X/Y positions on a printed page. We don't need them for decoding.

[JimBobSquarePants]

PR open #2788