Fix for UnrollAnyWordsPremul when extra channels are present

[mircomir]

I add skipping of extras as in UnrollAnyWords().

I had a problem with a TIFF image saved by Photoshop. Before using it in LittleCMS, I always convert the image from Planar to Chunky and tell LittleCMS that I don't want premultiplied alpha on output. I noticed the problem with the CMYK-to-RGB conversion.

I'm attaching a 16-bit CMYK TIFF with premultiplied alpha and an extra channel already converted to chunky with another software (Photoshop displays it correctly).

testcard16_cmykp5.tif

[mm2]

The current code only supports premultiplied alpha when one, and only one, extra channel is present, and that extra channel is the alpha channel.

This restriction is intentional. There are scenarios, such as premultiplied‑alpha output, where your proposed change would break the pipeline.

The most evident issue is when more than one extra channel is provided, there is no reliable way to determine which of them is the alpha channel.

If you really need this very specific decoder and you are aware of the side effects, you can implement your own unroll logic using a plug‑in. See the “Formatters Plug‑in” section in the Plug‑in API documentation.

[mircomir]

The current code only supports premultiplied alpha when one, and only one, extra channel is present, and that extra channel is the alpha channel.

This restriction is intentional. There are scenarios, such as premultiplied‑alpha output, where your proposed change would break the pipeline.

I'll check it again, but if I remember correctly:

1. It works with the same 8-bit image (the premultiplied is the first of the extras).
2. It also works correctly with premultiplied RGB alphas and multiple extra channels.

[mm2]

1. It works with the same 8-bit image (the premultiplied is the first of the extras).
2. It also works correctly with premultiplied RGB alphas and multiple extra channels.

You are completely right, as UnrollChunkyBytes() is doing this thing. At that point I am not sure if remove this functionality, which was never intended, or expand words also and replicate the alpha-is-first behavior.

[mircomir]

1. It works with the same 8-bit image (the premultiplied is the first of the extras).
2. It also works correctly with premultiplied RGB alphas and multiple extra channels.

You are completely right, as UnrollChunkyBytes() is doing this thing. At that point I am not sure if remove this functionality, which was never intended, or expand words also and replicate the alpha-is-first behavior.

I think it makes sense to say that alpha should be first.
Besides, it's already that way throughout the code. I haven't tried them, but UnrollDoublesToFloat and UnrollFloatsToFloat also add Extra to the accumulator.

If I may, I'd prefer this solution, which also maintains backwards compatibility with 8-bit. :)

PS: If it helps with your choice, Photoshop also set alpha first when I saved the image as a TIFF.

[mircomir]

PS: If it helps with your choice, Photoshop also set alpha first when I saved the image as a TIFF.

Same 8-bit test case saved by Photoshop. If you need them, feel free to use them. These are the ones I normally use in testing KDE Image Formats.

testcard8_cmykp5.tif

[mm2]

After seeing other cases are already using first extra as alpha, I gladly take your PR. Thank you!