[Date Prev][Date Next][Thread Prev][Thread Next][Date Index][Thread Index]
draft-ietf-fax-implementers-guide-06.txt
Please consider the following proposed revision section 5.2 of
draft-ietf-fax-implementers-guide-06.txt.
Summary of proposed revisions:
1. A new section 5.2.2 "Color Gamut Considerations" is added to address
difficulties, which may be experienced will transforming color data that was
sourced from a display, camera or a web application (e.g. sRGB data) to
ITULAB encoding.
2. Renumber the current section 5.2.2 as 5.2.3 and modify the title to be
consistent with that of the current 5.2.2.
3. Edited section 5.2.3 items a through t to a form that is more consistent
with providing directional guidance to implementers.
4. Clarification is need for section 5.2.3 item d, as I am unable to
determine the intent.
5. Please consider regrouping section 5.2.3 items a through t to provide
greater correlation between the items.
Lloyd
5.2 Precautions for implementers of RFC 2301 [4]
5.2.1 Errors encountered during interoperability testing
The TIFF/RFC 2301 [4] errors listed below were encountered during
interoperability testing and are provided so that implementers of
TIFF readers and writers can take precautionary measures.
a) Although Profile S of TIFF-FX [4] specifies that files should
be in little-endian order, during testing it was found that
some common TIFF writers create big-endian files. If possible,
the TIFF reader should be coded to handle big-endian files.
TIFF writers should always create little-endian files to be
compliant with the standard and to allow interoperation with
memory-constrained devices.
b) Bytes 0-1 of the Image File Header are supposed to be set to "II"
(4949h) or "MM" (4d4dh) to indicate the byte order. During
testing, other values were encountered. Readers should handle
cases where the byte order field contain values other than "II"
or "MM", and writers should ensure the correct value is used.
5.2.2 Color Gamut Considerations
The ITULAB encoding (PhotometricInterpretation = 10) allows choosing
a gamut range for L*a*b* (see the TIFF field Decode), which in turn
provides a way to place finer granularity on the integer values
represented in this colorspace. But consequently, an inadequate
gamut choice may cause a loss in the preservation of colors that
don't fall within the space of colors bounded by the gamut. As such,
it is worth commenting on this.
The ITULAB default gamut, L [0,100] a [-85,85] b [-75,125], was chosen
to accommodate most scan devices, which typically acquire from a
hardcopy source. It wasn't chosen to deal with the range of color
from camera input or sRGB monitor data. In fact, when dealing with
images from the web and other display oriented sources, the color
range for scanned hardcopy may likely be inadequate. It is important
to use a gamut that matches the source of the image data.
The following guidelines are recommended:
1. When acquiring input from a printed hardcopy source, without
modification, the ITU-T Recommendation T.42 default ITULAB gamut
should be appropriate.
2. For an sRGB source the ITU-T Recommendation T.42 default ITULAB
gamut is not appropriate. A more appropriate gamut to consider is:
L [0,100], a [-88,99] and b [-108.8,95.2]. These may be
realized by using the following Decode values for 8-bit data:
(0/1, 100/1, -22440/255, 25245/255, -27744/255, 24276/255).
3. If the range of L*a*b* value can be precomputed efficiently before
converting to ITULAB, then you may get the best result by picking
a gamut that is custom to this range.
5.2.3 Fileformat Considerations
TIFF-FX implementers should make sure that:
a) Readers only accept files with bytes 2-3 of the Image File Header
equal to 42 (2Ah), the "magic number", as being valid TIFF-FX
files, while writers only generate files with the appropriate
magic number.
b) Readers are able to handle cases where IFD offsets point beyond
the end of the TIFF-FX file, while writers ensure the IFD offset
does not point beyond the end of the file.
c) Readers are able to handle the first IFD offset being on a
non-word boundary, while writers ensure that the first IFD offset
is on a word boundary.
d) Readers and writers should be careful to correctly handle IFDs
with other TIFF profile data such as strip image data and
header data.
--> I am not clear as to what is being said by this item, please clarify.
e) Readers are flexible and able to accommodate: IFDs that are not
presented in ascending page order; IFDs that are not placed at a
location that precedes the image which the IFD describes; nextIFD
offsets that precede the current IFD, the current IFDs' field
data, or the current IFDs' image data. Writers on the other hand
should generate files with IFDs presented in ascending page order;
IFDs placed at a location that precedes the image which the IFD
describes; the next IFD should always follow the current IFD and
all of its data.
f) Files are not generated with missing field entries, and readers reject
any such files.
g) Writers generate tags with the appropriate type of data (for
example RATIONAL instead of SRATIONAL). Readers are flexible
with those types of misrepresentations that may be readily
accommodated (for example SHORT instead of LONG) and lead to
enhanced robustness.
h) The appropriate count is associated with the tags (it is not 0
and matches the tag requirement) while readers are flexible with these
types of misrepresentations, which may be readily accommodated and
lead to enhanced robustness.
i) Tags appear in the correct order in the IFD and readers are
flexible with these types of misrepresentations.
j) The PageNumber value is based on the order within the Primary IFD
chain. The ImageLayer values are based on the layer order and
the image order within the layer respectively. Readers may reject
the pages where the PageNumber or ImageLayer values are not consistent
with the number of Primary IFDs, number of layers or number of
images within the layers.
k) Tags are unique within an IFD and readers may reject pages where this
is not the case.
l) Strip data does not overlap other file data and the reader may
error appropriately.
m) The strip offset does not point outside the file, under these
conditions readers may reject the page where this is the case.
n) The strip offset + StripByteCounts does not point outside the
file, under these conditions the reader may error appropriately.
o) Only one endian order is used within the file otherwise the
rendered file will be corrupted.
p) Tag values are consistent with the data contained within the
image strip. For example, a bi-level black mark on white
background image strip with PhotometricInterpretation tag value
of "1" (bit value of "0" means black) will result in rendering of
the image as white marks on a black background (reverse video).
q) For the special color spaces (ITULAB, YCBCR, CMYK), the parameters
used for transformations are correct and compliant with the
specification.
r) The XPosition and YPosition values are consistent with the
horizontal and vertical offsets of the top-left of the IFD from
the top-left of the Primary IFD, in units of the resolution. To do
otherwise results in misplacement of the rendered image.
s) All combinations of tag values are correct, with special attention
being given to the sets: XResolution, YResolution and
ImageWidth; PhotometricInterpretation, SamplesPerPixel, and
BitsPerSample. Any appropriate combinations will likely result in
image distortion or an inability to render the image.
t) The appropriate Compression types are used for the image layers
within a Profile M file, such as a bi-level coder for the mask
layers (i.e. odd numbered layers) and multi-level (color) coders
for the background and foreground layers. Readers should reject
files where this is not true.
***********************************************
Lloyd McIntyre lmcintyre@xxxxxxxxxxxxxx
Xerox Corp., Xerox Architecture Center
3400 Hillview Ave. Bldg. 1
Palo Alto, CA 94304
Tel: +1 650 813 6762 fax: +1 650 813 6860
***********************************************