TIFF and LibTiff Mail List Archive


2012.10.16 05:36 "[Tiff] TIFF created by Kyocera 4550 Workstation is not able to be opened in MacOS X Preview", by Andrew Roughan
2012.10.16 21:34 "Re: [Tiff] TIFF created by Kyocera 4550 Workstation is not able to be opened in MacOS X Preview", by Chris Cox

2012.10.16 21:34 "Re: [Tiff] TIFF created by Kyocera 4550 Workstation is not able to be opened in MacOS X Preview", by Chris Cox


Compression code 6 is an obsolete form of JPEG compression that nobody should be using, and very few applications can read (it was abandoned partly because it was ambiguous, and JFIF defined a better stream). This is a serious bug on the part of Kyocera, and someone there failed to read all of the available TIFF documentation (specifically technotes 1 and 2).

Yes, you need to let Kyocera know that this sort of sloppiness is not acceptable and that they need immediate revision of their code to write useful TIFF files.


On 10/15/12 10:36 PM, "Andrew Roughan" <> wrote:

I have discovered that TIFF output from the Kyocera 4550 Workstation is not able to be viewed in MacOS X Preview, Pixelmator or Dropbox's web preview - although it can be viewed in Windows Picture Viewer - and I'd like to learn enough about the TIFF format to be able to blame the right company :-) So far I have looked at the TIFF specification, examined the binary content of the file and used TIFFTags and TIFFInfo applications to examine the tags and now I have some questions that I am hoping that someone with more experience with the format will be able to answer.

Here's the TIFFInfo report on the tags (~40KB) (tags in decimal)

Here's the TIFFTags report on the tags (~40KB) (tags in hex and some values interpreted)

Here's the file itself (~190KB)

The first problem I have found is that the spec says that the IFD "must begin on a word boundary". In this file, it does not as the IFD offset is an odd value.

In practice, is this a significant problem these days?

I modified the file to move the IFD to a word boundary and update the offset:

This does not allow viewing in Dropbox's web preview. I have yet to try opening it in MacOS X Preview, however I suspect it will still fail.

There are three tags that have no count and no content: 519 (207.h) JPEGQTables, 520 (208.h) JPEGDCTables, 521 (209.h) JPEGACTables.

This issue causes TIFFTags.exe to fall over, however I gather that is not a robust tool.

This does not seem to me to be a problem, because Windows Picture Viewer also

creates TIFF files with this content (e.g. after rotating the Kyocera


The most likely culprit is probably the compression type 6 which apparently is an old style of JPEG compression that should not be used any more - according to

"Obsolete 'old-style' JPEG, later overridden in Technote2" - "Obsolete, should never be written."

Can anyone confirm that this is the problem?

Personally, I think that Kyocera is not doing the right thing here and should be conforming to the later version of the specification - Technote 2.

Does anyone have any existing contact at Kyocera? Or have Kyocera equipment that is being used with Macs in the workplace? I can imagine that this would be easy to ignore without some leverage.

I opened a Apple Support Communities discussion on this topic - but I suspect that the likely outcome given the above information will be no hope of an update.

Thanks for any insight or assistance that you can provide.