TIFF files with unassociated extra samples are unsupported.

[Aerocatia]

TIFF files with 2 samples per pixel (Luminance + Alpha) are unsupported by this library.
Such TIFF files are the default output of imagemagick if the input is grayscale.

Attached is an example.
example_tiff.zip

[fintelia]

Do you know where specifically the error is coming from? GrayA is listed as a supported color type and I believe that most of the code doesn't care how many samples per pixel there are.

[197g]

It seems, imagemagick does not encode it as a truly alpha component but as a mask:

$ tiffinfo *
TIFF Directory at offset 0x80008 (524296)
  Image Width: 512 Image Length: 512
  Resolution: 1, 1 (unitless)
  Bits/Sample: 8
  Compression Scheme: None
  Photometric Interpretation: min-is-black
  Extra Samples: 1<unassoc-alpha>
  FillOrder: msb-to-lsb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 2
  Rows/Strip: 512
  Planar Configuration: single image plane
  Page Number: 0-1
  White Point: 0.3127-0.329
  PrimaryChromaticities: 0.640000,0.330000,0.300000,0.600000,0.150000,0.060000

This is probably intended in this case (pistol_scope_mask.tif) but quite possibly the reason that it's not commonly encountered or reported as such.

The library doesn't guess the meaning of extra channels and unassociated extra samples aren't supported.

[sophie-h]

I guess this is the same issue?

Format error decoding Tiff: Format error: invalid JPEG format: Invalid number of channels (4) for RGB data

If so, is the solution to change the check to "at least 3 channels" and just use the first 3 channels?

Triggered by Transparency_example.tiff generated via https://www.freeconvert.com

Downstream issue https://gitlab.gnome.org/sophie-h/glycin/-/issues/78

[sophie-h]

$ tiffinfo Transparency_example.tiff 
=== TIFF directory 0 ===
TIFF Directory at offset 0x8 (8)
  Image Width: 194 Image Length: 68
  Bits/Sample: 8
  Compression Scheme: JPEG
  Photometric Interpretation: RGB color
  Extra Samples: 1<unassoc-alpha>
  FillOrder: msb-to-lsb
  Orientation: row 0 top, col 0 lhs
  Samples/Pixel: 4
  Rows/Strip: 68
  Planar Configuration: single image plane
  Page Number: 0-1
  White Point: 0.3127-0.329
  PrimaryChromaticities: 0.640000,0.330000,0.300000,0.600000,0.150000,0.060000
  JPEG Tables: (289 bytes)

[sophie-h]

Maybe we can just use SamplesPerPixel – ExtraSamples as a default and special-case (1) where the premultiplication has to be undone? (Haven't looked at the code yet.)

0 = Unspecified data

1 = Associated alpha data (with pre-multiplied color)

2 = Unassociated alpha data

[Zet237]

Hello,

I just wanted to add another encounter with this issue.

Some cursor images from the quite old but still maintained application OpenMusic appear to be affected. The affected TIFF files are grayscale + alpha (YA8). They load fine in more permissive viewers (e.g. sxiv) and on other systems, but fail to load in GTK applications using image-rs (e.g. Loupe or Pinta via Glycin). This also caused the app itself to not work properly.

The OpenMusic developers use Debian themselves where they hadn't encountered the issue yet (see: openmusic-project/openmusic#301 (comment) ).

Here is one of the affected cursor files:
boxcur.zip

I was able to work around the issue locally by converting to RGBA using ffmpeg -i box-cursor.tif -vf format=rgba box-cursor-rgba.tif

I'm just sharing this in case the info is useful.

[197g]

@Zet237 More test files and use case backgrounds is always useful. Since you're converting to rgba should I assume that the alpha channel is highly relevant to you for reading? Would the color type Rgba(8) be the expected result by default or rather Rgb(8) with some additional configuration / method for extracting the unassociated samples separately?

[Zet237]

@197g Hello. Thank you for the reply!

Yes, the alpha channel is very relevant in the images as they are mouse cursors which include some transparent grey tones.
Rgba(8) would thus be the expected result.

I did convert to Rgba(8) because I noticed that some of OpenMusic's cursors worked while others didn't. Those that loaded without issue were all Rgba(8), so I concluded that converting them into this format should be a work around. The converted files worked fine.

Here are four more example files of two non-working TIFFs and two working ones. The working TIFFs load fine in GTK applications while the non-working ones throw the error above.

example_cursors.zip

[197g]

Tested all of these with #313, works great 👍