-
Notifications
You must be signed in to change notification settings - Fork 6.2k
8364583: ColorConvertOp fails for CMYK → RGB conversion #27785
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Closed
Closed
Changes from all commits
Commits
File filter
Filter by extension
Conversations
Failed to load comments.
Loading
Jump to
Jump to file
Failed to load files.
Loading
Diff view
Diff view
There are no files selected for viewing
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
51 changes: 51 additions & 0 deletions
51
test/jdk/java/awt/image/ColorConvertOp/ColorConvertOpCMYK.java
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
| Original file line number | Diff line number | Diff line change |
|---|---|---|
| @@ -0,0 +1,51 @@ | ||
| /* | ||
| * Copyright (c) 2025, Oracle and/or its affiliates. All rights reserved. | ||
| * DO NOT ALTER OR REMOVE COPYRIGHT NOTICES OR THIS FILE HEADER. | ||
| * | ||
| * This code is free software; you can redistribute it and/or modify it | ||
| * under the terms of the GNU General Public License version 2 only, as | ||
| * published by the Free Software Foundation. | ||
| * | ||
| * This code is distributed in the hope that it will be useful, but WITHOUT | ||
| * ANY WARRANTY; without even the implied warranty of MERCHANTABILITY or | ||
| * FITNESS FOR A PARTICULAR PURPOSE. See the GNU General Public License | ||
| * version 2 for more details (a copy is included in the LICENSE file that | ||
| * accompanied this code). | ||
| * | ||
| * You should have received a copy of the GNU General Public License version | ||
| * 2 along with this work; if not, write to the Free Software Foundation, | ||
| * Inc., 51 Franklin St, Fifth Floor, Boston, MA 02110-1301 USA. | ||
| * | ||
| * Please contact Oracle, 500 Oracle Parkway, Redwood Shores, CA 94065 USA | ||
| * or visit www.oracle.com if you need additional information or have any | ||
| * questions. | ||
| */ | ||
| import java.io.File; | ||
|
|
||
| import java.awt.color.ColorSpace; | ||
| import java.awt.image.BufferedImage; | ||
| import java.awt.image.ColorConvertOp; | ||
| import java.awt.image.ColorModel; | ||
|
|
||
| import javax.imageio.ImageIO; | ||
|
|
||
| /* | ||
| * @test | ||
| * @bug 8364583 | ||
| * @summary Verify CMYK images work with ColorConvertOp | ||
| */ | ||
|
|
||
| public class ColorConvertOpCMYK { | ||
|
|
||
| public static void main(String[] args) throws Exception { | ||
| String sep = System.getProperty("file.separator"); | ||
| String dir = System.getProperty("test.src", "."); | ||
| String prefix = dir + sep; | ||
| File file = new File(prefix + "black_cmyk.jpg"); | ||
| BufferedImage source = ImageIO.read(file); | ||
| ColorModel sourceModel = source.getColorModel(); | ||
| ColorSpace cs = ColorSpace.getInstance(ColorSpace.CS_sRGB); | ||
| ColorConvertOp convertOp = new ColorConvertOp(cs, null); | ||
| BufferedImage rgb = convertOp.filter(source, null); | ||
|
Contributor
There was a problem hiding this comment. Choose a reason for hiding this commentThe reason will be displayed to describe this comment to others. Learn more. rgb variable can be removed... |
||
| } | ||
| } | ||
Loading
Sorry, something went wrong. Reload?
Sorry, we cannot display this file.
Sorry, this file is invalid so it cannot be displayed.
Add this suggestion to a batch that can be applied as a single commit.
This suggestion is invalid because no changes were made to the code.
Suggestions cannot be applied while the pull request is closed.
Suggestions cannot be applied while viewing a subset of changes.
Only one suggestion per line can be applied in a batch.
Add this suggestion to a batch that can be applied as a single commit.
Applying suggestions on deleted lines is not supported.
You must change the existing code in this line in order to create a valid suggestion.
Outdated suggestions cannot be applied.
This suggestion has been applied or marked resolved.
Suggestions cannot be applied from pending reviews.
Suggestions cannot be applied on multi-line comments.
Suggestions cannot be applied while the pull request is queued to merge.
Suggestion cannot be applied right now. Please check back later.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Since this is executed for each pixel, it will generate garbage equal to the image size. Maybe we can cleanly split the usage of the two vars here? Note that the bug only occurs when the source image does not use an ICC profile, but this change would increase garbage for both ICC and non-ICC profiles.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
Uh oh!
There was an error while loading. Please reload this page.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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?
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
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.
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
Seems the destination handles it properly; I tested it with the following example:
There was a problem hiding this comment.
Choose a reason for hiding this comment
The reason will be displayed to describe this comment to others. Learn more.
@mrserb @prrace
Are we testing the else block - the one for "possible non-ICC src, possible CSList, possible non-ICC dst" with the test provided by Sergey?
Ln#872 in the else block has a similar line
color = srcCM.getNormalizedComponents(spixel, color, 0);and the above test runs fine if normComponents is set to either color or null.