Re: [Lcms-user] Embedded Profiles...

[<ma...@li...>]

Hi John,

I'm not shure to undestand where the problem is,
however embedded profiles is a quite interesting
stuff, I got crazy when trying to find some info
about it time ago. So here are some comments.
Since this is a sort of opinion too, please feel
free to correct me if I am wrong.

Some compex file formats, like TIFF, JPEG, PNG
has the ability of store embedded profiles. Embedded
profiles are nothing more that the whole profile file stored
in some way inside the image format. And why to do this?
Well, a image stored in non-colorimetric color spaces, like
RGB or CMYK is only a bunch of numbers. The interpretation
of these numbers is hardly device dependent. That is, a
RGB=100, 100, 100 can be rendered as a neutral gray
for one monitor, but can be bluish or definitively yellow
on others.

For accomplishing same colors, no matter wich monitor
is used, we need to use a device independent color space
as CIELab is used of TIFF format for example, Or identify
in some way wich color we are talking about when we say
RGB=100, 100, 100

Then, as a mean to characterize the RGB, we can include
a icc profile that does describe the "perfect" monitor intended
to display the image. And this is the embedded profile.

Of course this is not perfect. If our image comes directly
from a scanner, embedding the scanner profile will be most
times a bad move: scanner profiles tend to be as big as
300-400K So, it has no sense to add 300K to a image
of 14K only to characterize colors.

Another solution, could be to transform the image to any
known colorspace (like sRGB) and mark the image as
using this space. This is used by PNG format, when it
labels the image with the sRGB chunk.
This approach is good on small images and when the
quality required is not too high. Unfortunately, all transforms
are always lossy, and the sRGB image we obtain has probably
less gamut that the original one. We are sacrificing fidelity vs.
disk space.

Another approach is to store a reference to a profile instead of
whole profile. This is used by PICT format. In this case, our
example of 400K scanner profile is not stored, but only the
filename of profile.

And this could  be good, but unfortunately scanners tend to vary
across time, so all nice colors of an  image taken 3 months ago,
and pointing to a scanner profile, could be destroyed on recalibrating
this scanner. Higher end apps does mantain a database of profiles, but
the cost of this latter too hight  for a "normal" application.

The profiles more well suited for embedding are matrix-shaper ones.
These usually are about 3-5K and does relate to monitors. sRGB
standard profile, for example, belong to this category. CIE RGB,
Adobe RGB, ColorMatchRGB, CIE RGB. All Photoshop workspaces
are matrix-shaper profiles too.

Back to your original question.

littlecms has only one function to open embedded profiles,
cmsOpenProfileFromMem(). But note that this is equivalent
to save the block to a file, and then open this file as a profile.
For embedding profile is just inverse, you need to read whole
profile file into a memory block and then pass this memory block
to file format library.

JPEG EXAMPLE:

    in = fopen("sRGB.icm", "rb");
    len = fread(Block, filelenght(fileno(in), 1, in);
    fclose(in);
    write_icc_profile (cinfo, Block, len);

TIFF EXAMPLE:

    in = fopen("sRGB.icm", "rb");
    len = fread(Block, filelenght(fileno(in), 1, in);
    fclose(in);
    TIFFSetField(Tiff, TIFFTAG_ICCPROFILE,  Len, Block);

Hope this helps.
Martí Maria
The little cms project
http://www.littlecms.com
ma...@li...


----- Original Message -----
From: "John Gray" <gr...@ag...>
To: <lcm...@li...>
Sent: Sunday, June 24, 2001 11:47 AM
Subject: [Lcms-user] Embedded Profiles...


> Hello,
>
> I'm working on embedding profiles into the jpegs.
>
> I see the routines to embed profiles generally take a buffer, and len.
> Is there a way to generate this from a open profile handle, or do I need
> to get this from either an existing file or a profile I read out of image.
>
> I have the handle handy at the time of write.  I was hoping to generate
> what I need from the handle.
>
> Thanks,
>
> John
>
> --
> John Gray                           gr...@ag...
> AgoraNet, Inc.                      (302) 224-2475
> 102 E. Main Street, Suite 303       (302) 224-2552 (fax)
> Newark, De 19711                    http://www.agora-net.com
>
>
> _______________________________________________
> Lcms-user mailing list
> Lcm...@li...
> http://lists.sourceforge.net/lists/listinfo/lcms-user
>
>