8bim and iptc info confusion.

[shaun]

Hi,
I've been working on upgrading our software to work with 6.3.2 release of IM from 6.2.6 and think i might have found a bug. I've reverted back several revisions and the same error is present. I'm using the windows source release with VS2005.

Start photoshop and create an image with a clipping path, then save once as a jpg, and again as a tiff.

When calling "identify -verbose" on the tiff, the path is found and decoded.
When calling "identify -verbose" on the jpg, the path is not found, but the 8bim data is shown within the itcp profile.

running against the 6.2.6 release both tiff and jpg behave the same, showing 8bim data under itcp profile.

I found this while working with ClipPathImage function which couldnt handle jpg paths.

[magick]

Post a URL to one of your images so we can download and reproduce the problem. Once we do we'll get back to you with a solution.

[shaun]

tiff
http://www.zhaun.net/no.tif
jpg
http://www.zhaun.net/no.jpg

[magick]

We have a fix for the problem you reported. It will appear in the next point release of ImageMagick in a week or so. Thanks.

[shaun]

Thanks.

While testing, i also came across a problem with SVG rendering. after getting the 8bim property and using the value for BlobToImage the result is a white image. Saving that data to a .svg file, then rendering with previous version I found that 6_2_9 can render the same file, while later versions cannot.

the file is at http://www.zhaun.net/no.svg

tested with the convert function "convert no.svg no.jpg"

[magick]

You need to change the fill and stroke from #00000000 to #000000FF in your SVG. We follow standards as closely as possible. Until recently there was no standard for the hex alpha channel of a color, now there is a defacto standard that says 00 is completely transparent for the alpha channel. However, not everyone is in agreement on this issue. How was your clip path generated? Whoever generated it, what is there standard for an alpha channel encoded as a hex color?

[shaun]

The clip path (the no images) were created in photoshop cs2. I'll look at photoshop and see if there are any options for the path that i have not seen regarding opacity. I've ran it against other images (jpgs, tiffs) and i'm experiencing the issue on all images.

that svg file can be drawn from the following, (you can extract it from no.tif above). I can change it on my application, but i'm getting the svg path from the print statement in the following code which comes from IM.

Code: Select all

  key=AcquireString(pathname);
  (void) FormatMagickString(key,MaxTextExtent,"8BIM:1999,2998:%s",pathname);
  attribute=GetImageAttribute(image,key);
  printf("%s",attribute->value);

  image_info=CloneImageInfo((ImageInfo *) NULL);
  clip_mask=BlobToImage(image_info,attribute->value,strlen(attribute->value), &image->exception);

the svg file i linked to was copied from the print statement above, and the white image result is coming from the clip_mask.

[magick]

Turns our a number of clip paths we found have a stroke/fill color of #00000000 generated by Adobe. However, a four byte hex color is not defined by CSS/SVG standards so you need to find out how Adobe intends this color to be interpreted. We found TCl is interpreting it as #argb whereas Ink is interpreting it as #rgba as ImageMagick does. If you find out what Adobe's intent is with a 4 byte hex color perhaps we can come to a concensus.