Tif to jpg conversion gives wrong colors..

[mmx]

Hello,

After suggestions I post this a possible bug!

I say "possible" because I am really new to imagemagick so I cannot tell that I tried everything..

This subject was first posted in the users section..
viewtopic.php?f=1&t=24401&p=104722#p104676

######################## QUOTE #############################
I searched almost all the web in order to find out why my .tif is converted to .jpg with wrong colors..

I tried many solutions that worked for others but not for me..

One of the latest commands I tried is the following (I 've tried several ones).

convert -profile img_profiles/CMYK/USWebUncoated.icc -profile img_profiles/RGB/sRGB.icc mytif.tif dest.jpg

here is the link for the .tif and .jpg files
http://makis.partyreports.com/mytif.tif
http://makis.partyreports.com/dest.jpg


I spent 2 days trying on finding a way to solve this with no luck..

The system is (Debian 4.4.5-8)
ImageMagick 6.6.0.4
################################################################

Thank you!

[fmw42]

For reference to the IM developers. The conversion problem seems to have to do with JPG compression in the tif file (with CMYK tif). If the compression is changed in Photoshop to LZW, IM handles it fine. But one cannot change the compression properly in IM to LZW and get the right result. See viewtopic.php?f=1&t=24401#p104684

[magick]

Adobe Photoshop writes inverted data in CMYK JPEG files. We tried a few other open-source TIFF viewers and they return the same colors as ImageMagick.

The JPEG library states:

CAUTION: it appears that Adobe Photoshop writes inverted data in CMYK JPEG files: 0 represents 100% ink coverage, rather than 0% ink as you'd expect. This is arguably a bug in Photoshop, but if you need to work with Photoshop CMYK files, you will have to deal with it in your application. We cannot "fix" this in the library by inverting the data during the CMYK<=>YCCK transform, because that would break other applications, notably Ghostscript. Photoshop versions prior to 3.0 write EPS files containing JPEG-encoded CMYK data in the same inverted-YCCK representation used in bare JPEG files, but the surrounding PostScript code performs an inversion using the PS image operator. I am told that Photoshop 3.0 will write uninverted YCCK in EPS/JPEG files, and will omit the PS-level inversion. (But the data polarity used in bare JPEG files will not change in 3.0.) In either case, the JPEG library must not invert the data itself, or else Ghostscript would read these EPS files incorrectly.

[fmw42]

I tried both of these but they do not produce the correct result.

convert mytif.tif -profile /Users/fred/images/profiles/USWebCoatedSWOP.icc -profile /Users/fred/images/profiles/sRGB.icc -negate mytif1.jpg

convert mytif.tif -compress LZW -profile /Users/fred/images/profiles/USWebCoatedSWOP.icc -profile /Users/fred/images/profiles/sRGB.icc -negate mytif2.jpg

[magick]

Find us an open-source package that returns the proper colors for this image and we'll investigate further. We need some assurances that the image is not corrupt before we are willing to investigate further.

[fmw42]

Find us an open-source package that returns the proper colors for this image and we'll investigate further. We need some assurances that the image is not corrupt before we are willing to investigate further.

The image would appear to be fine, since I can chance the compression to LZW in PS and it works fine.

CAUTION: it appears that Adobe Photoshop writes inverted data in CMYK JPEG files: 0 represents 100% ink coverage, rather than 0% ink as you'd expect. This is arguably a bug in Photoshop, but if you need to work with Photoshop CMYK files, you will have to deal with it in your application.

I guess it is not that simple to deal with the negate internally in IM.

[Jason S]

Your embedded JPEG data claims to be (and is) YCCK-transformed CMYK, but as far as I know there is no standard way to use that color format in a TIFF file. I suspect that IM is not doing the YCCK-to-CMYK transformation.

The TIFF container adds nothing to this particular file. If I strip it off, the resulting JPEG seems to be okay (albeit negated).

Most likely, the application that made this file always puts the JPEG data at offset 8. So you could try

Code: Select all

$ tail -c +9 mytif.tif | convert JPEG:- -negate dest.jpg

[magick]

The bug is likely in the TIFF library then. For this image, we call the TIFF delegate library method, TIFFReadRGBAImage(), which is supposed to return RGBA pixels from any TIFF image. Try posting this bug to the TIFF mailing list.

[dlemstra]

It took almost a year but the next version of ImageMagick (6.8.9-10) will be able to read your file. The pixels are stored as YCCK instead of CMYK. The next version will detect this an create the image with correct colors. You can see the result here: https://www.dropbox.com/s/nfhb3i3fcrf63 ... f.jpg?dl=0.