Re: TIFF Compression JPG with CMYK
Posted: 2011-12-21T09:17:07-07:00
Heiler81:
I just downloaded tesbild_CMYK_8Bit_E1_JPG.tif and 104023_121_05.tif from your ftp server. (Had to remember to set the transfer type to image. It's been a while since I last used ftp.)
The program described at http://libvips.blogspot.com/2011/12/tas ... nvert.html detects 104023_121_05.tif as being CMYK without an embedded profile. The result with the default profile (from HP) is strange: some patches look kind of OK, but some background figures become "ghosts," and strange colours run around. P.S. This is why I now think that this may have to do with LZW compression.
The other image (tesbild_CMYK_8Bit_E1_JPG.tif) I can't tell if it looks right because it is some sort of Macbeth colour checker. However, it has an embedded profile, so I'm pretty sure the program converts it just fine. P.S. Not so sure anymore, but it does look normal. Could libtiff/libvips do OK with LZW if it is tagged as such, but not if it's stripped? I'll need to check the EXIF of the 104023_121_05.tif image when I have a minute.
It is trivial to modify the program so it produces something else than sRGB JPEG. I consult for money, and this is a short job.
I opened the 104023_121_05.tif image in nip2 and tried 16 different Adobe CMYK ICC (downloaded from http://www.adobe.com/support/downloads/ ... ileID=3790) in addition to the built in one (from HP). None of them give good results, irregardless of what rendering intent I toggle. I have not tried extracting the ICC which is built into the tesbild_CMYK_8Bit_E1_JPG.tif image.
As you may know, TIFF is sometimes described as "Thousands of Incompatible File Formats" because it comes in all kinds of nonstandard variants. I don't think this is the issue here.
What I think is going on with 104023_121_05.tif is that it was produced with a very unusual CMYK ICC, and because none is embedded, we have no way of knowing how to convert the colours correctly without trying ICCs of various origins, targets and rendering intents until hitting one that just happens to be close to what was used to produce it. Assuming the original one was not so unusual that we'd have to reverse engineer it (through colour remapping).
CMYK is a very broadly defined family of colour profiles: For every ink set and printing medium, a different CMYK...
Quick notes RE: installation of nip2:
I don't think that libvips and nip2 have packaged installation for Solaris (although you may try to google nip2 install solaris). See http://www.vips.ecs.soton.ac.uk/index.p ... =Supported.
Then:
nip2 104023_121_05.tif
Left click on the bar to the left of the thumbnail (to tag it as the input to the next command).
Toolkit -> Colour -> ICC -> Import
There is no embedded profile, so the corresponding toggle does nothing.
If you click on Default Input Profile, you can substitute other ones (nip2 only comes with one CMYK profile, but the button opens a file browser which you can use to select alternates).
As mentioned earlier, none of the Adobe ICCs gave a good result. Neither did the nip2 default.
I just downloaded tesbild_CMYK_8Bit_E1_JPG.tif and 104023_121_05.tif from your ftp server. (Had to remember to set the transfer type to image. It's been a while since I last used ftp.)
The program described at http://libvips.blogspot.com/2011/12/tas ... nvert.html detects 104023_121_05.tif as being CMYK without an embedded profile. The result with the default profile (from HP) is strange: some patches look kind of OK, but some background figures become "ghosts," and strange colours run around. P.S. This is why I now think that this may have to do with LZW compression.
The other image (tesbild_CMYK_8Bit_E1_JPG.tif) I can't tell if it looks right because it is some sort of Macbeth colour checker. However, it has an embedded profile, so I'm pretty sure the program converts it just fine. P.S. Not so sure anymore, but it does look normal. Could libtiff/libvips do OK with LZW if it is tagged as such, but not if it's stripped? I'll need to check the EXIF of the 104023_121_05.tif image when I have a minute.
It is trivial to modify the program so it produces something else than sRGB JPEG. I consult for money, and this is a short job.
I opened the 104023_121_05.tif image in nip2 and tried 16 different Adobe CMYK ICC (downloaded from http://www.adobe.com/support/downloads/ ... ileID=3790) in addition to the built in one (from HP). None of them give good results, irregardless of what rendering intent I toggle. I have not tried extracting the ICC which is built into the tesbild_CMYK_8Bit_E1_JPG.tif image.
As you may know, TIFF is sometimes described as "Thousands of Incompatible File Formats" because it comes in all kinds of nonstandard variants. I don't think this is the issue here.
What I think is going on with 104023_121_05.tif is that it was produced with a very unusual CMYK ICC, and because none is embedded, we have no way of knowing how to convert the colours correctly without trying ICCs of various origins, targets and rendering intents until hitting one that just happens to be close to what was used to produce it. Assuming the original one was not so unusual that we'd have to reverse engineer it (through colour remapping).
CMYK is a very broadly defined family of colour profiles: For every ink set and printing medium, a different CMYK...
Quick notes RE: installation of nip2:
I don't think that libvips and nip2 have packaged installation for Solaris (although you may try to google nip2 install solaris). See http://www.vips.ecs.soton.ac.uk/index.p ... =Supported.
Then:
nip2 104023_121_05.tif
Left click on the bar to the left of the thumbnail (to tag it as the input to the next command).
Toolkit -> Colour -> ICC -> Import
There is no embedded profile, so the corresponding toggle does nothing.
If you click on Default Input Profile, you can substitute other ones (nip2 only comes with one CMYK profile, but the button opens a file browser which you can use to select alternates).
As mentioned earlier, none of the Adobe ICCs gave a good result. Neither did the nip2 default.