RE: TIFF-FX ImageBaseColor's photometry
"Dale Knutsen" <[email protected]>
| Newsgroups | gmane.ietf.fax |
|---|---|
| Message-ID | <[email protected]> |
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 protected]>
Date: Wed, 1 Aug 2001 18:54:31 -0700
To: "'[email protected]'" <[email protected]>
Subject: RE: TIFF-FX ImageBaseColor's photometry
> 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 protected]]
> > Sent: Saturday, July 28, 2001 10:25 AM
> > To: [email protected]
> > 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