RFR: 8364583: ColorConvertOp fails for CMYK → RGB conversion
Phil Race
prr at openjdk.org
Fri Oct 24 21:50:02 UTC 2025
On Fri, 24 Oct 2025 21:22:40 GMT, Sergey Bylokhov <serb at openjdk.org> wrote:
>> You mean keep the original returned float[] color separate from the one that's later over-written.
>> I'd thought about that but I don't think it is worth it.
>> It can also be over-written at line 835. There's just too much state tracking needed to save
>> the GC a tiny bit of effort freeing small transient objects.
>> Also it already is re-initialised for each scanline. See line 807, so it isn't (quite) the same array for the entire image anyway.
>
>> It can also be over-written at line 835.
>
> Interesting, is it possible that that line has the same bug?
> `color = dstColorSpace.fromCIEXYZ(dstColor);`
> Does dstColor always have the same number of components as CIEXYZ?
>
> Is the logic of using CIEXYZ for mix of non-/ICC source and non-/ICC destination actually correct?
fromCIEXYZ is defined on ColorSpace, not ICC_ColorSpace.
It requires 3 (or more) components, and then dstColorSpace will return an array of colors in its own colorspace.
The dstColor parameter is always created with at least 3 components based on the dstNumComp
And if there's no bug in dstColorSpace it should return an array of the right length for itself.
So if there's a bug it isn't obvious to me.
-------------
PR Review Comment: https://git.openjdk.org/jdk/pull/27785#discussion_r2462083087
More information about the client-libs-dev
mailing list