LibTiff Mailing List

Folks,

This is to inform you that I've received two files that the current
OJPEG decoder in CVS can't handle. Details are below. I mean to fix this
as soon as possible, which is likely by January next year.

If you find any other files that don't seem to work, please don't
hesitate to mail me, unless you know for a fact they correspond to the
descriptions below of the files sent to me already.

* One seems to be written by "Kofax standard Multi-Page TIFF Storage
Filter v3.03.000", judging from the Software tag. Seeing they write
OJPEG, I take it they mean the word "standard" a bit ironically.

LibTiff reports the error "Fractional scanline not read".

Strangely, my own proprietary codec that works much the same as the new
OJPEG decoder in LibTiff, handles this file just fine. This indicates
there is probably some trouble in the surrounding code in LibTiff,
possibly some scanline length calculation, and not in the actual OJPEG
codec.

* The other one seems to be written by "Microsoft Office Document
Scanning 11.0.1897.00" judging from that same Software tag.

The IFD indicates 1 sample per pixel, photometric MinIsBlack. Yet, the
JPEG compressed data contains three channels. LibTiff properly errors
out, saying "JPEG compressed data indicates unexpected number of
samples", which makes sense.

The JPEG compressed data, by itself, is legit. Even though it has three
channels, it doesn't contain any obvious color judging from a visual
inspection.

It is not enterely clear to me what would be the best solution.
Depending on the writer's intention, which is anyone's guess, I may
either want to add a hack to the surrounding library that corrects the
IFD to read 3 samples per pixel, photometric YCbCr, or I may either want
to add a hack inside the OJPEG codec to return the first Y sample of the
JPEG data only. The first option would be correct if the writer's
intention is to actually (not) interchange grayscale data, the second
would be correct if the lack of color in this particular file's JPEG
compressed data is merely coïncidence.

Best regards,

Joris Van Damme
info@awaresystems.be
http://www.awaresystems.be/
Download your free TIFF tag viewer for windows here:
http://www.awaresystems.be/imaging/tiff/astifftagviewer.html


AWARE [SYSTEMS]		Imaging expertise for the Delphi developer
		TIFF and LibTiff Mailing List Archive
	LibTiff Mailing List TIFF and LibTiff Mailing List Archive November 2006 Previous Thread Next Thread Previous by Thread Next by Thread Previous by Date Next by Date Contact The TIFF Mailing List Homepage This list is run by Frank Warmerdam Archive maintained by AWare Systems	2006.11.08 17:07 "OJPEG - two troublesome flavours", by Joris Van Damme Folks, This is to inform you that I've received two files that the current OJPEG decoder in CVS can't handle. Details are below. I mean to fix this as soon as possible, which is likely by January next year. If you find any other files that don't seem to work, please don't hesitate to mail me, unless you know for a fact they correspond to the descriptions below of the files sent to me already. * One seems to be written by "Kofax standard Multi-Page TIFF Storage Filter v3.03.000", judging from the Software tag. Seeing they write OJPEG, I take it they mean the word "standard" a bit ironically. LibTiff reports the error "Fractional scanline not read". Strangely, my own proprietary codec that works much the same as the new OJPEG decoder in LibTiff, handles this file just fine. This indicates there is probably some trouble in the surrounding code in LibTiff, possibly some scanline length calculation, and not in the actual OJPEG codec. * The other one seems to be written by "Microsoft Office Document Scanning 11.0.1897.00" judging from that same Software tag. The IFD indicates 1 sample per pixel, photometric MinIsBlack. Yet, the JPEG compressed data contains three channels. LibTiff properly errors out, saying "JPEG compressed data indicates unexpected number of samples", which makes sense. The JPEG compressed data, by itself, is legit. Even though it has three channels, it doesn't contain any obvious color judging from a visual inspection. It is not enterely clear to me what would be the best solution. Depending on the writer's intention, which is anyone's guess, I may either want to add a hack to the surrounding library that corrects the IFD to read 3 samples per pixel, photometric YCbCr, or I may either want to add a hack inside the OJPEG codec to return the first Y sample of the JPEG data only. The first option would be correct if the writer's intention is to actually (not) interchange grayscale data, the second would be correct if the lack of color in this particular file's JPEG compressed data is merely coïncidence. Best regards, Joris Van Damme info@awaresystems.be http://www.awaresystems.be/ Download your free TIFF tag viewer for windows here: http://www.awaresystems.be/imaging/tiff/astifftagviewer.html

LibTiff Mailing List

2006.11.08 17:07 "OJPEG - two troublesome flavours", by Joris Van Damme