First things first, update InDesign to 11.3.
But it’s entirely possible that the TIFF is indeed being created in a way that is keeping it from being imported. Have you tried other settings from the creating application?
OK, I will upgrade ID to 11.3 now.
Yes, I tried every possible setting... maybe you are interested in the Java application so you can try it yourself?
Then it would appear to be some kind of incompatibility.
You could fix it by running a batch action in Photoshop. Even if you have hundreds of them it wouldn’t take too long.
Thanks for the tip, but I definitely need some kind of solution to make my Java application work...
I will PM you the Java test app. so you can reproduce it.
Already upgraded to ID 11.3 as well, problem remains.
Sorry, John, but I don’t work for Adobe and don’t have time to test this now.
>> What can I do to be able to generate TIFF files with ZIP compression that open correctly in Adobe InDesign?
Just convert TIFF in PSD by Bridge/Photoshop and import psd.
That download link is on an ESET blacklist page. Can you post a link to just the jpeg, preferably on Dropbox or some different file service?
I'm not keen on running your app (I will if necessary), but it would be very instructive to have the jpeg YOU created that is not working for you.
Any jpeg will do...
If you run the program and try to add the generated TIFF to an ID doc, then it will generate the error message.
1 person found this helpful
According to Baseline TIFF Tag Compression (TIFFTAG_COMPRESSION), code 259 (0x0103) compression type 8 is the Adobe standard Flate compression documented in TIFF Supplement 2 http://partners.adobe.com/public/developer/en/tiff/TIFFphotoshop.pdf
Meanwhile compression type 32946 is described as "not part of the specification and are somewhat less common". So it is best to avoid less common non-standard codes if you want portability. Offering a choice is good, because Flate itself was late to the party, and lot of software with old codebases will only support LZW.
"Additionally, LibTiff adds support for some compression schemes that are not part of the specification and are somewhat less common. Here's LibTiff's definition of possible values:
COMPRESSION_DEFLATE = 32946;
COMPRESSION_ADOBE_DEFLATE = 8;"
We're talking about a tiff file!
Sorry, mis-typed. I meant I wanted the TIFF that was causing the problem.
FIXED: It turns out that I needed to use "ZLib" for compression instead of "Deflate".
Thank you all for your help!
FileFormats Adobe Deflate Compression
The TIFF (Tagged Image File Format) library supports various types of compression. The compression type is stored as a tag (an integer value) in the file.
Originally, the TIFF library had support for LZW (Limpel-Zev Welch) compression. Unfortunately, there was a patent on this compression scheme. The TIFF added gzip compression (which is patent free) to avoid legal issues. The developers of the TIFF library created a new tag value (the tag COMPRESSION_DEFLATE had a value of 32946) to indicate that gzip compression was used.
Adobe decided that they didn't like the COMPRESSION_DEFLATE value and decided to create a new compression style called ADOBE_DEFLATE (which had an integer value of 8 instead). This compression method uses exactly the same functions for compression/decompression as the COMPRESSION_DEFLATE tag, but has a different tag value.
In their wisdom, some versions of software from Adobe do not support the ADOBE_DEFLATE tag.
I would try, as a test, to patch the tags to 8, just to see if it is the tag that is checked! According to the information above, the compression algorithm is the same. If it does not work, it would be interesting to have a tiff checker program to scan the Tiff file.