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

From: "McIntyre, Lloyd" <[email-masked]>
Date: Mon, 12 Mar 2001 17:48:23 -0800

> -----Original Message-----
> From: Hiroshi Tamura [mailto:[email-masked]]
> Sent: Sunday, March 11, 2001 3:29 PM
> To: [email-masked]; [email-masked]
> Cc: [email-masked]; [email-masked];
> [email-masked]; [email-masked]
> Subject: Re: draft-ietf-fax-implementers-guide-06.txt
> 
> 
> I wanted your comments at much earlier stage.
> 
> > 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.
> 
> OK for me.
> 
> > 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.
> 
> OK for me.
> 
> > 3. Edited section 5.2.3 items a through t to a form that is 
> more consistent
> > 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
> > determine the intent.
> 
> Mike,
> Could you please comment it?
> If not, I will delete this item d.
> 
> > 5. Please consider regrouping section 5.2.3 items a through 
> t to provide
> > 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?
This is effectively correct. 
This is only a cosmetic comment -> The items in Section 5.2 could be
organized so as to create two groups - items for which the reader is being
advised to be more flexible and those which an error response may be more
appropriate. Example current b,c,e,g,h and i encourage greater flexibility
while a,f,j,k,l,m,n,o,p,q,r,s,and t tend to encourage an error.  One could
reorganize so that b,c,e,g,h and i are not a,b,c,d,e and f and listed under
recommended increased flexibility while a,f,j,k,l,m,n,o,p,q,r,s,and t would
g,h,i, -----
> 
> > 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
> > ***********************************************
> 
> Regards,
> --
> Hiroshi Tamura, Ricoh Company, LTD.
> E-mail: [email-masked]
>

---

From: Hiroshi Tamura <[email-masked]>
Date: Tue, 13 Mar 2001 12:18:12 +0900 (JST)

I am a little confused.

> recommended increased flexibility while a,f,j,k,l,m,n,o,p,q,r,s,and t would

I do not see the above.

Are you proposing the following two new section ?
one section that includes b,c,e,g,h and i
the other section that includes a,f,j,k,l,m,n,o,p,q,r,s,and t
If so, what are the new section's title?

If "Cosmetic" is not so important, I would like the following,
except for item d for that we need Mike confirmation.

Could you please clarify for my *editing* ?

Regards,