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,
Marti Maria
The little cms project
http://www.littlecms.com
[EMAIL PROTECTED]
 
----- 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

Reply via email to