Hi,
The problem both you mention is not trivial. Has to do with
what is known as "color workflows" and is one of the things
that IMHO makes color management so difficult.
So, I have no magic recipe to solve that, but here are
some guidelines I've successfully used when writting
imaging software.
- Take those viewer/browser/editor/converter programs
as a device translators. In this way, viewing would be a
translation from file to monitor, printing a translation from
file to printer, scanning a translation from scanner to file,
and so one. File to file is just one case like others.
- Then for any translation, you need to define in which
colorspace operates each device. An ICC profile may be
handy in this case. So, if you have to display a file image
you would need the image data, a profile describing the
image colorspace and a profile describing your monitor.
- lcms color transforms deals with such concept. You
cannot apply a single profile to an image. Only a color
transform from a profile to another profile makes sense.
A color transform is just a translation to be applied to
raster data in order to convert from source color space
to destination color space. Color is kept, encoding is
changed.
- And here comes the magic: the colorspaces of source and
destination have NOT to be the same. For example, you can
convert form RGB to CMYK just having a RGB profile as
source and a CMYK profile as destinatione. Of course RGB to
RGB works fine too, but this is just one of the possible cases.
- Some devices may have no ICC profile available, but instead
other data that characterizes the device. In that situations,
lcms provides "virtual" profiles. That is, functions that creates
profiles "on the fly" based on some parameters.
Actually you can do that on RGB, Gray, Lab and XYZ
color spaces.
- For other cases, some "default profile" should be specified.
That is how applications like photoshop does work. You can
say, "ok, let's assume any untagged data comes in sRGB space"
Please note this scheme does not use the concept of
"workspace". That belogs to image editors and is meaningful
when modifying images.
Does make sense to you?
BTW, Bob, I've been using the Rec709 YCbCr as default
for tiff images without problems. Any intent but absolute colorimetric
should handle white point mismatches, so even for D65 based
image data seems to works great.
Regards
Marti.
-------------------------------------------------------
This SF.net email is sponsored by: Splunk Inc. Do you grep through log files
for problems? Stop! Download the new AJAX search engine that makes
searching your log files as easy as surfing the web. DOWNLOAD SPLUNK!
http://ads.osdn.com/?ad_id=7637&alloc_id=16865&op=click
_______________________________________________
Lcms-user mailing list
Lcms-user@lists.sourceforge.net
https://lists.sourceforge.net/lists/listinfo/lcms-user
