|
Hi,
Well, your best move would be to save the original
block of memory and embed back to the destination image.
And there are very good reasons to do it in such
way instead of openprofile and savetomem:
At first, there is no one-to-one correspondence
between a serialized profile (stored in file) and the image in memory cmsOpenProfileXXX does create. Some examples: LUT
tables can be stored in 8 or 16 bits of
precision. lcms does _always_ expand the 8 bits ones to 16 bits in memory. Thus,
if you open a 8 bits profile and the save it, you
will end with a different representation of LUT, but otherwise equivalent.
Curves can be stored in file as algorithm
instead of value. Ver 2 holds only simple gamma, but ver 4 can have complex math expressions, with conditionals. lcms does expand
such expressions in tables, using proper
resolution. So, the original math _expression_ is lost. More, private tags are (as
spec states) ignored, thereby they are not in
memory and cannot be saved.
Other no so evident reasons is the on-demand
loading of AToB/BToA lcms has This makes
saving of profile more complex, too.
So, right now, _cmsSaveProfile and
cmsSaveProfileToMem should be used only to save profiles created
by:
cmsCreateRGBProfile,
cmsCreateGrayProfile,
cmsTransform2Devicelink,
cmsCreateLinearizationDeviceLink,
cmsCreateInkLimitingDeviceLink,
cmsCreateLabProfile,
cmsCreateXYZProfile,
cmsCreate_sRGBProfile
Which are the profile creation
functions.
There is another method for creating profiles,
which involves opening NEW profile with "w"
cmsOpenProfileFromFile(cProfile, "w")
cmsAddTag()
cmsCloseProfile()
Anyway, editing of profiles is a very desirable
feature, and I do not discard to add it in future versions.
Regards,
----- Original Message -----
Sent: Monday, August 18, 2003 6:27
PM
Subject: Re: [Lcms-user] Problems with
cmsSaveProfile and cmsSaveProfileToMem()
Thanks Marti for your reply.
I wasn't trying to edit the profile, but
merely use it, and then embed it back into the tif file. Here's what I
mean:
(1) Open a tif (or jpeg)
(2) Read the raw bytes of the profile into a
memory buffer.
(3) "Open" the profile using
cmsOpenProfileFromMem().
(4) Use the profile to translate file colors into
screen colors via a transform with a monitor profile.
(5) Do whatever editing to the
image.
(6) Save the tif file, along with the embedded
profile again, using cmsSaveProfileToMem() followed by writing the raw bytes generated to the tif (or
jpeg) file.
This seems like a very common thing to want to
do, so I was surprised when it didn't work. It doesn't involve any editing of
the profile, just merely using it for color transformations.
The work-around I figured out was to keep the
original memory buffer I had read in (2), and then write that memory
buffer
back out, that is, never calling
cmsSaveProfileToMem(). This of course means I have to keep that memory buffer
around along with the "working" version of the profile, resulting in some
redundancy.
What I wasn't able to work around so easily was
the scenario where you want to save the profile, but continue using it.
(Perhaps you are sharing a copy across multiple images being edited.) This
can't be done, because the mere saving of the profile renders the tags
unusable. Or are the tags not really used for transformations? I can't say I
tried that, because once I saw the tags were being corrupted, I didn't look
any further.
Other than these problems, so far the package has
been working great!
Bryan
----- Original Message -----
Sent: Monday, August 18, 2003 1:38
AM
Subject: Re: [Lcms-user] Problems with
cmsSaveProfile and cmsSaveProfileToMem()
Hi Bryan,
Your are right, however, this is not a bug
but an area to improve.
Currently, lcms does *not* support editing of
profiles.
That is, you can open a profile and use it in
transforms. You can also CREATE a
profile and save it to memory or disk. But
currently, you cannot open a profile, touch some tags and then save it. This would imply a wider understanding of
all tags, and some are still not used by
lcms.
Take for example sRGB, it has luminance tag and
viewing condition tags. lcms does not use these, so there is no code to write them.
Also, many profiles has custom tags. Opening in edit mode would imply a
handling of these and this is not supported
right now.
It happens that in the design of lcms API, long
time ago, I belived this would be a nice feature, and as such the API gives the possibility of this
combination. Yes, this is how it wuld work (with perhaps an additional
"r+" in open profile function) But this part is still just planned. I'm adding a
error message to prevent such corruption.
Regards,
----- Original Message -----
Sent: Sunday, August 17, 2003 6:58
PM
Subject: [Lcms-user] Problems with
cmsSaveProfile and cmsSaveProfileToMem()
Hi,
I've recently started experimenting with the
littlecms package for possible use in an image-editing program I've been
writing. This package is much appreciated, and would appear to be just
what I need. However, I've noticed three "features" so far, in the day and
a half I've been using it. These problems have to do with tags, and the
opening and saving of profiles for embedded use:
(1) It seems the _cmsSaveProfile() and
_cmsSaveProfileToMem() functions have some issues. If you call these
functions, the profile is corrupted, because the tag directory gets
damaged. More specifically, the TagSizes[] array internal to the lcms
profile structure gets modified during the save operations, (specifically
in the SaveTags() function), rendering the tags unusable.
It seems to me that saving a profile should
not render it unusable for further operations.
(2) Also, another problem I've encountered
when using embedded profiles: A profile created with
_cmsOpenProfileFromMem() cannot be saved properly with _cmsSaveProfile()
or _cmsSaveProfileToMem(). Basically, the tags created with
_cmsOpenProfileFromMem() are not in the right form for saving, so they get
dropped, resulting in a corrupt profile. So, for example, if I want to
"copy" a profile from a tiff file I've opened, back to the tiff file after
editing, I have to copy the raw buffer I obtained from
_cmsOpenProfileFromMem(), rather than try to save the profile using the
handle created from _cmsOpenProfileFromMem().
(3) There appears to be no way to copy a
profile in memory, at least with a convenient function call. So if you
wish to save a profile to a memory buffer (for embedding in tiff and jpeg
files) or to a file, but still continue to use that profile for internal
color conversions, you can't, because the profile gets corrupted, and you
can't even make a copy of it beforehand.
One workaround I've come up with is to
follow any call to _cmsSaveProfileToMem() with a call to
_cmsOpenProfileFromMem(), using the same buffer. Then the profile is
usable --- to a point. You can use it alright, you just can't ever save it
again! (Due to issues #1 and #2.)
Am I doing something wrong, or are these
legitimate bugs?
Otherwise, the package seems to be working
smoothly, and is very much appreciated. It's some of the cleanest open
source code I've encountered, as far as readability is concerned. And it
compiles with no errors or warnings, which is always a good
sign.
Thanks,
Bryan
Flamig
|
