AWARE [SYSTEMS] | Imaging expertise for the Delphi developer |
|||||||

TIFF and LibTiff Mailing List Archive | ||||||||

## LibTiff Mailing List
TIFF and LibTiff Mailing List Archive Contact
The TIFF Mailing List Homepage |
## Thread## 1999.06.21 07:12 "Re: Controlling Rational Values", by Niles RitterBjorn 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. |