RE: TIFF-FX ImageBaseColor's photometry

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.

> -----Original Message-----
> From: Dale Knutsen [mailto:[email protected]]
> Sent: Thursday, August 02, 2001 5:24 AM
> To: [email protected]; [email protected]
> Cc: 'IETF fax WG'
> Subject: RE: TIFF-FX ImageBaseColor's photometry
> 
> 
> 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