AWARE [SYSTEMS] Imaging expertise for the Delphi developer
TIFF and LibTiff Mailing List Archive

LibTiff Mailing List

Contact

The TIFF Mailing List Homepage
This list is run by Frank Warmerdam
Archive maintained by AWare Systems

1999.06.21 07:12 "Re: Controlling Rational Values", by Niles Ritter

```Bjorn Brox wrote:

> Why make it so complex?

The solution is as simple as the nature of the general problem I had to solve,
and no simpler.

> I have never seen x/y resolution defined with decimals.

If the resolution is always of the form X / 1, where X is an integer,
then the appropriate unit for resolution should have been integer.
I have no doubt that for original scanned data this will be the case.

However, if absolute size of a scanned target is important, and the original
scanning resolution was 200:1, and if in an image processing program
the original data was downsized by a factor of three, then the resulting
TIFF image tags should be updated to read 200 / 3.

>
>
> Therefore: storing 200.0 as something else than 200/1 seems stupid, and makes
> it more difficult to "debug" tiff files.

I agree, but that section of code in libtiff is for any rational tag,
of which the following are required to be expressed as rational values or arrays:

XPosition
YPosition
WhitePoint
PrimaryChromaticities
YCbCrCoefficients

In the YCbCr case the most common values look like (exactly) 0.299 ,  0.7154   and

so on.  The XPosition, YPosition are placement parameters of the top of
the image with respect to the top of the page. Values such as 1/2 and 3/4 inch
would not be uncommon.

These numbers still aren't too bad, since they can be represented with
denominators of powers of ten, but for some extreme numbers a power of ten is
not going to do the value justice.  For example, the inverse of 2^32 can
only be expressed to a single decimal point of precision with powers
of ten, but can be expressed exactly with a power of two in the denominator.

I have run into cases where this became an issue.

I personally don't think RATIONAL was such a good idea, since this could
have been addressed with double-precision IEEE floating point. But since its in
the
spec, and since the libtiff interface wants to implement it by passing the
computed value, the continued fraction solution presents itself.

And, more to the point, it gave me an excuse to do some fun
mathematics while being paid for it (okay, so I have weird idea of fun)...

--Niles.
```