Subject: RE: TIFF-FX ImageBaseColor's photometry

From: "McIntyre, Lloyd" <[email-masked]>
Date: Wed, 1 Aug 2001 18:54:31 -0700

Dale,
Thank you for your review and comments.

As you have stated, there is benefit to be gained by relaxing the
ImageBaseColor constraints to accommodate use of the image data color
encoding parameters, as opposed to only ITULAB, to interpret ImageBaseColor
when the IFD contains image data. We explored many avenues to try and
accommodate this request but in the end concluded that it was not possible
to do so without creating issues for TIFF-FX base (i.e. RFC 2301 or a
revision of) readers. 

Our thought process follow the lines that ImageBaseColor relaxation may be
reasonably accommodated for TIFF-FX Extension Set 1 readers and writers.
This is, however, not true for TIFF-FX base readers, since there are
numerous TIFF-FX implementations deployed within the market and no way to
signal a change from default ITULAB interpretation of ImageBaseColor to that
of some other color space. The problem is manifested when a TIFF-FX base
reader unknowingly decodes a TIFF-FX Extension Set 1 file (unknowingly
because a TIFF-FX reader should ignore the unrecognized TIFF-FXExtension
field that accompanies all extension files) in which ImageBasecolor
interpretation is the only encoding change from a comparable TIFF-FX file.
The result is that the colors of the ImageBaseColor regions would be wrong
and the reader would have no way of predicting or detecting the error.

In conclusion we must regrettably deny your request to permit other color
spaces to be used in the interpretation of ImageBaseColor.

Regards,  
Lloyd

> -----Original Message-----
> From: Dale Knutsen [mailto:[email-masked]]
> Sent: Saturday, July 28, 2001 10:25 AM
> To: [email-masked]
> Subject: ImageBaseColor's photometry: Redefine to be simple, 
> convenient,
> practical
> 
> 
> 
> I am working on software implementing a TIFF-FX reader, and I
> have found the current definition of ImageBaseColor in TIFF-FX
> to be rather impractical, and I recommend changing it as
> described below.
> 
>     The Problem
> 
> The color sample data contained in the ImageBaseColor field is
> specified to be in photometry ITU L*a*b*. Notice that this
> photometry may be DIFFERENT than that of the image that is
> being represented. 
> 
> For example, consider TIFF generator software which has an
> input image with photometry CMYK; the software is rendering
> this image into a TIFF-FX data stream. If the generator notices
> a strip whose color is constant, the generator could achieve
> excellent compression by representing the constant color in
> ImageBaseColor and setting the strip byte count to zero.
> 
> HOWEVER, the generator is faced with the daunting task of
> representing the CMYK (in this example) constant color in ITU
> L*a*b* color space. This requires:
> 
> (a) the generator must have the mapping from device-dependent
> CMYK photometry to the colorimetric ITU L*a*b* photometry;
> typically this is done by having the appropriate ICC profile
> and applying it to the CMYK. However, the generator may not
> have the profile data available for a variety of reasons.
> 
> (b) the generator must incorporate the complicated algorithms
> (color space conversion, ICC profile processing) -- which are
> not required otherwise of the generator.
> 
> Similar problems occur to software reading a TIFF data stream. 
> 
>     Analysis and Proposal
> 
> It seems to me that the motivation behind of ImageBaseColor is
> to provide an efficient way to represent strips of constant
> color. Of course we want it to be simple and practical too --
> which I think the present definition is not. 
> 
> I propose that that the photometry and interpretation of the
> ImageBaseColor field data be changed to be IDENTICAL TO that of
> the containing IFD (including all applicable fields which
> modify the representation and photometric interpretation of
> color sample data). This means that the representation of
> ImageBaseColor sample data would be identical to the
> representation of the ordinary color sample data that it
> represents (stands in place of). This would be extremely simple
> and convenient, both for the creator of a TIFF data stream and
> for the reader of a TIFF data stream! There would be NO
> difference in the treatment of ordinary color sample data and
> the color sample data in the ImageBaseColor field. 
> 
> 
>     Dale Knutsen
> 
> -- 
> 
> 
> 
>     Dale Knutsen
> 
> 
> _______________________________________________
> Get your free email from http://webmail.earthlink.net
>

---

From: "Dale Knutsen" <[email-masked]>
Date: Thu, 02 Aug 2001 20:23:53 +0800

Lloyd,

Thanks for your thoughtful reply. I understand the
requirement for backward compatibility. And in that light I
offer the following proposal, which might be found to meet
all concerns.

In TIFF-FX Extension Set 1, define a new field, I'll call it
NewImageBaseColor, that is the same as ImageBaseColor except
that the photometry and interpretation of the
NewImageBaseColor field data is specified to be identical to
that of the containing IFD (including all applicable fields
which modify the representation and photometric
interpretation of color sample data).

For a writer of a TIFF-FX Extension Set 1 data set who
wishes to use NewImageBaseColor, to conform to the base
TIFF-FX standard the writer will include the standard
ImageBaseColor field as well as the NewImageBaseColor field.
This is no benefit to the writer, but it is extremely simple
and easy to do, and so adds negligible costs to the writer.

The benefit of the proposed change accrues to the reader of a
TIFF-FX Extension Set 1 data set, who may use the following
algorithm when dealing with a strip that has a strip byte
count of zero:

   IF NewImageBaseColor is present, then use its content to
   render the color in the color space of the image of which
   the strip is a part. This is simple, accurate, and very
   efficient.

   ELSE Use the ImageBaseColor field. If the color space of
   the image of which the strip is a part has photometry
   other than ITULAB, the reader must convert the
   ImageBaseColor data to the required output photometry.

As you know, I claim that this conversion (of ITULAB to an
arbitrary photometry) is onerous and problematical in many
system environments. Nevertheless, the addition of
NewImageBaseColor provides to readers of a TIFF-FX Extension
Set 1 data set an efficient, accurate, and simple way of
rendering fill colors in cases where the writer has utilized
NewImageBaseColor, while at the same time not significantly
increasing the complexity of software required to support
both TIFF-FX Extension Set 1 as well as the base TIFF-FX
standard.

    Dale Knutsen

-----Original Message-----
From: "McIntyre, Lloyd" <[email-masked]>
Date: Wed, 1 Aug 2001 18:54:31 -0700 
To: "[email-masked]'" <[email-masked]>
Subject: RE: TIFF-FX  ImageBaseColor's photometry

-- 

    Dale Knutsen

---

From: "McIntyre, Lloyd" <[email-masked]>
Date: Sat, 4 Aug 2001 15:02:03 -0700

Dale,
We have reconsidered and accepted your latest proposal to use a new field in
accommodating use of the image color encoding parameters rather than only
ITULAB in the interpretation of ImageBaseColor. 

Our decision was base on:
1. Since there is currently no mechanism to enable ICC profiles in TIFF-FX,
your concern for the impact of profiles doesn't currently come into play.
However, we'd like to make sure that we don't preclude it's future use.

2. In the current use of TIFF-FX, if ICC profiles *were* used, then it would
likely be in one of two situations:
  a. A closed environment, where an input device is preparing a file for a
known output device.  In this case, both devices not only need to know how
to deal with ICC profiles, but they should make sure that they enable the
full use of the profiles.  In this case, we believe the reader and writer
should have full access to algorithms that can apply the profiles.  The end
result is that profiles shouldn't be an inhibitor.
  b. An open environment.  In this case the preference might be to maintain
a device-independent color space.  Otherwise, the profiles ought to be dealt
with correctly, and ought to be well understood (algorithms available).

3. In the remote but likely case that someone gets a file with the image
data coupled to an ICC profile, and the ImageBaseColor is not, there's the
risk that the image data will contrast with the "default color" of the
ImageBaseColor, notably when compared to the original.  The contrast is
relative, such that if the default and image data had the same wrong ICC
profile applied, the contrast should not stand out.  However, with the
current ImageBaseColor approach, the image color will be perceptibly
different from that of the adjoining color derived from the ImageBaseColor -
this becomes the most important factor.

Given the expectation that ICC profiles may one day work themselves into
TIFF-FX, we feel it prudent to make provisions in the use of ImageBaseColor
for consistent color data.  We are proposing the following new field, to be
used in place of ImageBaseColor, when using TIFF-FX extensions (any file
containing the TIFF-FXExtension field).

The new field, IFDBaseColor, is defined within a new subsection "E1.2.1.3.2
New fields required for designated profiles" as below.

Regards,
Lloyd

E1.2.1.3.2 New fields required for designated profiles

IFDBaseColor Field
   This field applies to Profiles M and T, however it is only
   recommended for Profile T. The IFDBaseColor field is introduced as a
   duplication of ImageBaseColor, which is tied to the ITU L*a*b* color
   space, as a way to keep the color space of the image data in sync
   with that of the 0-byte strips.  This should not be a significant
   factor when device-independent color data is present, but may be a
   factor should device-dependent image data be considered, coupled with
   the device-independent color value stored in ImageBaseColor.  More
   notably, if ICC Profiles were to be used, it is possible that
   misinterpretation of the image data may cause the ImageBaseColor to
   contrast.  Keeping the color interpretation in sync would avoid
   possible contrasting.  Furthermore, color space conversion
   differences to and from ITU L*a*b* and the intended color space could
   be avoided.

   In keeping with the constraint that this extension set requires no
   modification of existing TIFF-FX implementations, this field SHALL be
   used only when the TIFF-FXExtensions field is present, and SHOULD
   exist along with the ImageBaseColor field. When both fields are
   present, the IFDBaseColor field takes precedence, and it's at the
   discretion of the writer to determine the color values that will go
   into the ImageBaseColor, knowing that a base TIFF-FX reader will see
   only the ImageBaseColor. If extensions are used to the point that a
   base TIFF-FX reader may not be able to reasonably read the image
   anyway, the ImageBaseColor MAY be omitted.

IFDBaseColor(34700).                                       CHAR or SHORT
   Count = SamplesPerPixel
   In areas of an image layer where no image data is available (i.e.
   where no strips are defined, or where the StripByteCounts entry for a
   given strip is 0), the color specified by IFDBaseColor SHALL be used,
   and SHOULD exist along with the ImageBaseColor field.  This field is
   used in a similar manner to ImageBaseColor, but is tied to the color
   characteristics of the IFD, not ITU L*a*b*.

   The color specified by IFDBaseColor SHALL be described by the color
   characteristics of the IFD: PhotometricInterpretation,
   SamplesPerPixel, BitsPerSample and, depending on the value of
   PhotometricInterpretation, all other fields of the IFD that affect
   the interpretation of color samples. For example, if the
   PhotometricInterpretation is ITU L*A*B*, then the color is further
   described by the gamut defined in the Decode field, if any, and by
   the Indexed field where applicable. This insures that the
   IFDBaseColor is represented in exactly the same way as any image
   data that is represented.

   Note that there is currently no provision for color profile data in
   TIFF-FX.

   Each color component may be stored in a CHAR array, if BitsPerSample
   is 8 or less.  If BitsPerSample is less than that of the IFDBaseColor
   array element (8 for CHAR and 16 for SHORT), then the 'BitsPerSample'
   least-significant bits are used to hold the color component(s).  For
   example, if BitsPerSample is 4, then the lower 4 bits in each CHAR or
   SHORT will hold the color components.

   Other than color designation, IFDBaseColor is used as described by
   ImageBaseColor.
   To define a child IFD specifying a IFDBaseColor but containing no
   encoded image data, create an IFD with PhotometricInterpretation,
   SamplesPerPixel, BitsPerSample and any other field(s) required to
   specify color Characteristics. The IFD will also contain the
   following settings.

      ImageLayer[0]:             specified layer
      ImageLayer[1]:             less than any other IFDs corresponding
                                 to the same layer and strip.
      RowsPerStrip:              strip height
      ImageLength:               strip height
      ImageWidth:                full image width
      Compression:               1 (none)
      X/YResolution:             that of the Primary IFD
      XPosition:                 0
      YPosition:                 the offset from the top of the page to
                                 the beginning of the strip in the 
                                 resolution units of inches
      StripByteCounts:           single 0 value
      StripOffsets:              single 0 entry
      NewSubFileType:            bit 4 set   (MRC)
      ImageBaseColor:            desired color

   For the Foreground layer image(s), the default value for the
   IFDBaseColor field is black. For other cases, including the
   Background layer image, the default value is white.

> Sent: Thursday, August 02, 2001 5:24 AM
> To: [email-masked]; [email-masked]
> Cc: 'IETF fax WG'