Backward comp of color_profile and iptc_profile impossible
Posted: 2007-06-24T04:25:28-07:00
Hi,
This looks very much like my previous post, but read on
I am using JMagick, which at several places use the ImageMagick API as it was
used in 2003, including the use of color_profile and iptc_profile members.
IMs changelog states:
2003-09-21 Cristy <yarrow@image...>
* Image profiles are now conveniently handled with a hashmap
structure. The color_profile and iptc_profile members of the Image
structure are still maintained for backwards compatibility, however,
we encourage you to use the new PutImageProfile(), GetImageProfile(),
and DeleteImageProfile() methods.
However JMagick not only *reads* but altso *writes* to the color_profile and iptc_profile members.
When saving file to disk later on the new hashtable structure for profiles is of course used,
therefore new values of color_profile and iptc_profile members are NOT stored.
For example in JMagick/src/magick/magick_MagickImage.c line 3376:
/*
* Class: magick_MagickImage
* Method: setColorProfile
* Signature: (Lmagick/ProfileInfo;)V
*/
JNIEXPORT void JNICALL Java_magick_MagickImage_setColorProfile
(JNIEnv *env, jobject self, jobject profile)
{
Image *image = (Image*) getHandle(env, self, "magickImageHandle", NULL);
if (image == NULL) {
throwMagickException(env, "Cannot obtain image handle");
return;
}
setProfileInfo(env, &image->color_profile, profile);
}
which calls JMagick/src/magick/jmagick.c line 732, which is shown in
viewtopic.php?f=2&t=9021&p=28005
but essentially sets these variables:
image.color_profile.name = <some string>
image.color_profile.info = <a byte array>
image.color_profile.length = <length of byte array>
As said these new values are ignored when the image is saved to disk later on.
So, backward compatibility of color_profile and iptc_profile seems impossible.
Only solution I can come up with would be to always check the old deprecated
members for new values and transfer them if they have changed.
Seems a little cumbersome to me.
Alternatively it should be stated that color_profile and iptc_profile and other
deprecated members are *read only* and state that any code that changes
them will be broken.
Jacob
This looks very much like my previous post, but read on
I am using JMagick, which at several places use the ImageMagick API as it was
used in 2003, including the use of color_profile and iptc_profile members.
IMs changelog states:
2003-09-21 Cristy <yarrow@image...>
* Image profiles are now conveniently handled with a hashmap
structure. The color_profile and iptc_profile members of the Image
structure are still maintained for backwards compatibility, however,
we encourage you to use the new PutImageProfile(), GetImageProfile(),
and DeleteImageProfile() methods.
However JMagick not only *reads* but altso *writes* to the color_profile and iptc_profile members.
When saving file to disk later on the new hashtable structure for profiles is of course used,
therefore new values of color_profile and iptc_profile members are NOT stored.
For example in JMagick/src/magick/magick_MagickImage.c line 3376:
/*
* Class: magick_MagickImage
* Method: setColorProfile
* Signature: (Lmagick/ProfileInfo;)V
*/
JNIEXPORT void JNICALL Java_magick_MagickImage_setColorProfile
(JNIEnv *env, jobject self, jobject profile)
{
Image *image = (Image*) getHandle(env, self, "magickImageHandle", NULL);
if (image == NULL) {
throwMagickException(env, "Cannot obtain image handle");
return;
}
setProfileInfo(env, &image->color_profile, profile);
}
which calls JMagick/src/magick/jmagick.c line 732, which is shown in
viewtopic.php?f=2&t=9021&p=28005
but essentially sets these variables:
image.color_profile.name = <some string>
image.color_profile.info = <a byte array>
image.color_profile.length = <length of byte array>
As said these new values are ignored when the image is saved to disk later on.
So, backward compatibility of color_profile and iptc_profile seems impossible.
Only solution I can come up with would be to always check the old deprecated
members for new values and transfer them if they have changed.
Seems a little cumbersome to me.
Alternatively it should be stated that color_profile and iptc_profile and other
deprecated members are *read only* and state that any code that changes
them will be broken.
Jacob