Skip to main content

Re: [JAI-IMAGEIO] POLL: How should ICC profiles be handled by ImageReaders?

4 replies [Last post]
Anonymous

Included below is my previously posted suggestion for handling ICC profiles
embedded in the TIFF ICCProfile field. The second paragraph mentions
performance. As it turns out there *is* a display performance penalty
associated with using an embedded ICC profile in preference to a standard
color space. While this does not argue persuasively against using the profile
automatically in the case of CMYK images, for example, as the result is
otherwise quite incorrect, an argument could be made against using the
profile in the case of RGB images: in my testing the displayed RGB images show
no readily apparent difference when the ICC profile was used as opposed to
the standard sRGB color space.

However despite the performance penalty I tend to stand by the suggestion
included below. At least in that case one knows that the result is numerically
correct.

Does anyone have any other comment on this topic?

Brian

---------- Forwarded message ----------

> For what it's worth, my opinion is that if an ICC profile is available in the
> image file, be that in a TIFF field or in a JPEG marker segment, then that
> ICC profile should be used to create the ColorSpace contained in the
> ColorModel which is by default attached to the image. If in addition the
> color space type is one for which a "standard" ColorSpace object is
> available, be that
> SimpleCMYKColorSpace or one associated with one of the
> java.awt.color.ColorSpace.CS_* constants, then ImageReader.getImageTypes()
> should return an Iterator containing ImageTypeSpecifiers for both ColorModels
> (I'm ignoring the possibility of there being more than two). The
> ImageReader.getRawImageType() method should return the ImageTypeSpecifier
> correspnoding to the ICC profile. With this approach if the application does
> not want to use the ColorModel based on the ICC profile it can use
> ImageReadParam.setDestinationType() to specify the ImageTypeSpecifier to be
> attached to the image after having obtained the alternate type using
> getImageTypes().
>
> With respect to the performance comment, I would suggest that if performance
> issues were encountered when using the ICC profile color space then bugs
> should be filed and those problems fixed in J2SE. I am not sure whether I
> really observed problems with performance of this nature or whether my
> recollection is faulty. In any case that was some time ago and if there were
> any problems they might well have been addressed by now.

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Reply viewing options

Select your preferred way to display the comments and click "Save settings" to activate your changes.
Andreas Schildbach

Brian Burkhalter wrote:

> [...]
>
> However despite the performance penalty I tend to stand by the
> suggestion included below. At least in that case one knows that the
> result is numerically correct.

I'm not an expert on image processing, but I'd say top priority should
always be correctness, with performance standing back some places. So
respecting an included color profile should be the default action.
Having an option to override the color profile is useful as well. I
can't say anything about the concrete implementation though.

Adding to the performance discussion, bear in mind that the current
situation is not very performant: color profiles, which I guess are
stored in the image as a byte stream, are converted into a string of
comma seperated integer values, which need then be parsed back into a
byte array by the application.

Regards,

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Brian Burkhalter

On Mon, 30 Jan 2006, Andreas Schildbach wrote:

> Brian Burkhalter wrote:
>
>> [...]
>>
>> However despite the performance penalty I tend to stand by the suggestion
>> included below. At least in that case one knows that the result is
>> numerically correct.
>
> I'm not an expert on image processing, but I'd say top priority should always
> be correctness, with performance standing back some places. So respecting an
> included color profile should be the default action. Having an option to
> override the color profile is useful as well. I can't say anything about the
> concrete implementation though.

The override would be available as the second ImageTypeSpecifier in
ImageReader.getImageTypes().

> Adding to the performance discussion, bear in mind that the current situation
> is not very performant: color profiles, which I guess are stored in the image
> as a byte stream, are converted into a string of comma seperated integer
> values, which need then be parsed back into a byte array by the application.

In the proposed fix this would become unnecessary. I guess your statement is
an argument in favor of a performance gain to offset a loss.

Brian

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Andreas Schildbach

Brian Burkhalter wrote:

> In the proposed fix this would become unnecessary. I guess your
> statement is an argument in favor of a performance gain to offset a loss.

Yes, that's what I wanted to say.

One more thought:

If I would read a TIFF/CMYK image with a color profile attached with the
updated codec, the TIFF would still stay in the CMYK color space, would it?

I'm asking because another usecase I have in addition to my first one:

I need to convert TIFF/CMYK to JPG/CMYK _and_ the color profile needs to
be transferred. I guess this is only possible if the TIFF image isn't
forced to RGB by the reader?

Side question: Is it possible to attach the color profile to a JPEG
image with the JPG codec?

Regards,

Andreas

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net

Brian Burkhalter

On Thu, 2 Feb 2006, Andreas Schildbach wrote:

> Brian Burkhalter wrote:
>
>> In the proposed fix this would become unnecessary. I guess your statement
>> is an argument in favor of a performance gain to offset a loss.
>
> Yes, that's what I wanted to say.
>
> One more thought:
>
> If I would read a TIFF/CMYK image with a color profile attached with the
> updated codec, the TIFF would still stay in the CMYK color space, would it?

Yes. The only difference would be in the ColorSpace object contained in the
ColorModel of the image.

> I'm asking because another usecase I have in addition to my first one:
>
> I need to convert TIFF/CMYK to JPG/CMYK _and_ the color profile needs to be
> transferred. I guess this is only possible if the TIFF image isn't forced to
> RGB by the reader?

Yes.

> Side question: Is it possible to attach the color profile to a JPEG image
> with the JPG codec?

At present not with the JAI-Image I/O Tools JPEG writer. You can write
an image with a profile however with the Java SE Image I/O JPEG writer. I
don't know the exact details but they are given here:

http://java.sun.com/j2se/1.5.0/docs/api/javax/imageio/metadata/doc-files...

If the writer handles CMYK images directly then it will be easy. Otherwise you
might have to supply an IIOImage containing a Raster and an IIOMetadata tree
containing an app2ICC element.

Brian

----------------
Brian Burkhalter
Java Media, Imaging, and Graphics
Sun Microsystems, Inc.

~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~
This email message is for the sole use of the intended recipient(s)
and may contain confidential and privileged information. Any
unauthorized review, use, disclosure or distribution is prohibited.
If you are not the intended recipient, please contact the sender by
reply email and destroy all copies of the original message.
~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~~

---------------------------------------------------------------------
To unsubscribe, e-mail: interest-unsubscribe@jai-imageio.dev.java.net
For additional commands, e-mail: interest-help@jai-imageio.dev.java.net