Subject: draft-ietf-fax-implementers-guide-06.txt

From: "McIntyre, Lloyd" <[email-masked]>
Date: Fri, 9 Mar 2001 14:38:08 -0800

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        [email-masked]
Xerox Corp., Xerox Architecture Center
3400 Hillview Ave. Bldg. 1
Palo Alto, CA 94304
Tel: +1 650 813 6762   fax: +1 650 813 6860
***********************************************

---

From: Hiroshi Tamura <[email-masked]>
Date: Mon, 12 Mar 2001 08:29:29 +0900 (JST)

I wanted your comments at much earlier stage.

> sourced from a display, camera or a web application (e.g. sRGB data) to

OK for me.

> consistent with that of the current 5.2.2.

OK for me.

> with providing directional guidance to implementers.

OK for me.

> 4. Clarification is need for section 5.2.3 item d, as I am unable to

Mike,
Could you please comment it?
If not, I will delete this item d.

> greater correlation between the items.

So, McIntyre-san
Are you proposing section 5.2 as the followings, except for item d?
Could you reply to me?

>       realized by using the following Decode values for 8-bit data:

Regards,
--
Hiroshi Tamura, Ricoh Company, LTD.
E-mail: [email-masked]