resizing tiff cmyk files

[gursch]

I found a problem resizing tiff / cmyk files. For example: convert test.tif -resize 200x200 out.tif. The colors are inverted and the black channel gets lost.
Here is a sample file: http://dl.dropbox.com/u/1973423/test.tif

[fmw42]

Works fine for me in IM 6.7.5.5 Q16 Mac OSX Snow Leopard. What version are you using? Perhaps an upgrade is in order.

[Drarakel]

Did you use Mac Preview, Fred?
With IM 6.7.5-5 Q16 on Windows XP, it doesn't work.

It's a problem of reading CMYK JPG in TIFF. I was curious and searched the version where it changed. The bug came with v6.6.4-4, it seems.

"identify -verbose" with e.g. test.tif shows:
Type: ColorSeparation
Base type: TrueColor
Colorspace: CMYK

And the black channel was also added to the CMY channels.
In versions up to 6.6.4-3, type and base type are "ColorSeparation" and the channels are correct.

Another quick test:

Code: Select all

convert logo: -colorspace CMYK -compress ZIP tif:- | convert tif:- -colorspace RGB logo1.jpg

Code: Select all

convert logo: -colorspace CMYK -compress JPEG tif:- | convert tif:- -colorspace RGB logo2.jpg

[fmw42]

I was a bit hasty in my reply. I only looked at the verbose info and it looked fine with no loss of black channel. Upon closer inspection although everything looks fine in the statistics, the image colors as displayed seem to be reversed or changed drastically even for a simple copy. I use his image test.tif.tiff

convert test.tif.tiff test2.tiff

and also a resize

convert test.tif.tiff -resize 200x200 test3.tiff

Both the original and the simple copy have CMYK channels and the values are nearly identical though not exact (as it should be). So some changes in CMYK values are taking place on a simple copy. However, no stats seem to be changed very much. Even the endian on all 3 is reported as lsb. Perhaps it got reversed, but not showing in the stats.

Type: ColorSeparation
Base type: TrueColor
Endianess: LSB
Colorspace: CMYK


So I cannot really explain the difference in the appearance. Yes I used Mac Preview to view all 3 images. They also all display the same in PS as in Mac Preview

[magick]

The TIFF delegate library does not support CMYK JPEG-compressed image although it does not complain when you ask for it. We added a patch to not use JPEG compression when the image is in the CMYK colorspace.

[fmw42]

The TIFF delegate library does not support CMYK JPEG-compressed image although it does not complain when you ask for it. We added a patch to not use JPEG compression when the image is in the CMYK colorspace.

Just curious, but will IM/libtiff handle reading CMYK tiff images with JPG compression after your patch or only use a different compression when set to JPG on output?

What about the report by Drarakel, that the base type has been changed in recent versions from ColorSeparation to Truecolor, even in the input image. Is that a factor here? Correct me if I am wrong as I am not versed in this, but I thought CMYK images were always colorseparation by definition.

[magick]

What about the report by Drarakel, that the base type has been changed in recent versions from ColorSeparation to Truecolor, even in the input image.

Code: Select all

convert logo: -colorspace cmyk logo.tif
identify -verbose logo.tif
Image: logo.tif
  Format: TIFF (Tagged Image File Format)
  Class: DirectClass
  Geometry: 640x480+0+0
  Resolution: 72x72
  Print size: 8.88889x6.66667
  Units: Undefined
  Type: ColorSeparation
  Base type: ColorSeparation
  Endianess: MSB
  Colorspace: CMYK

[magick]

Found the problem. Libtiff has a generic read method that returns RGBA pixels. We need to bypass the generic method for CMYK JPEG images. We'll have a patch in ImageMagick 6.7.5-7 Beta by sometime tomorrow.

[fmw42]

What about the report by Drarakel, that the base type has been changed in recent versions from ColorSeparation to Truecolor, even in the input image.

Code: Select all

convert logo: -colorspace cmyk logo.tif
identify -verbose logo.tif
Image: logo.tif
  Format: TIFF (Tagged Image File Format)
  Class: DirectClass
  Geometry: 640x480+0+0
  Resolution: 72x72
  Print size: 8.88889x6.66667
  Units: Undefined
  Type: ColorSeparation
  Base type: ColorSeparation
  Endianess: MSB
  Colorspace: CMYK

Interesting, the image from the first poster at http://dl.dropbox.com/u/1973423/test.tif, reports

Type: ColorSeparation
Base type: TrueColor
Endianess: LSB
Colorspace: CMYK

[antonellad]

I am using ImageMagick 6.7.5-6 for Windows (ImageMagick-6.7.5-6-Q16-windows-dll.exe) and I have a problem that seems related to the bug reported here.
I have to resize black&white .tif files to 80% of their dimension.
The command

Code: Select all

convert test.tif -resize 80% test_80.tif

does the job, but the resized file presents a bright green background.
If I change the destination format (e.g. .gif or .jpg) the problem disappears.

[fmw42]

Post a link to your tiff file so the IM developers or others can check and test with it.

[antonellad]

Here they are:
https://oxfile.ox.ac.uk/oxfile/work/ext ... B4187DF3F3

Test.tif is the original file and Test_80.tif is the resized file.
They will be available at that url from today to 08 Mar 2012.
Many thanks!

[fmw42]

Here they are:
https://oxfile.ox.ac.uk/oxfile/work/ext ... B4187DF3F3

Test.tif is the original file and Test_80.tif is the resized file.
They will be available at that url from today to 08 Mar 2012.
Many thanks!

Both your images look just fine to me in several viewers on Mac OSX Snow Leopard including IM display (IM 6.7.5.7 Q16). They are both just black and white.

Double check the images you uploaded (download them and see if they look OK). Otherwise, what viewer are you using?

[antonellad]

I use Windows (I tried with XP and Vista) and I have to use the tiff files in a mail merge using Microsoft Word.
I have found the problem using Microsoft Office Picture Manager (SP3) and Microsoft Office Word 2007 (SP3), when inserting/merging the image.

[gursch]

Resizing the tiff cmyk files works now. But now resizing the tiff rgb files corrupts the colors.

Tested using ImageMagick 6.7.6-5 2012-04-04 Q16