Hello Alexander,
Thanks for picking up this issue. I actually worked on it a little last week as
well but did not yet finish a patch.
The TIFF 6.0 specification does not provide any guidance on the handling of
rational values in terms of the three questions at hand:
1 - Should the rational values be stored as given or with common factors
divided out?
2 - Should the displayed form of rational values be fractions as given (if
these are not reduced before being stored), fractions with common factors
divided out, or real values obtained by floating point division?
3 - Should providing a rational value with a zero denominator be an error?
Also, the libtiff tools ‘tiffdump’ and ‘tiffinfo’ seem to handle rational
values inconsistently. For example, for the images in the libtiffpic set of
sample images, XResolution and YResolution are reported to have a value such as
“72” instead of “72/1”, the values of ReferenceBlackWhite are displayed as-is,
but those of YCbCrCoefficients are divided out to real values.
My preference right now leans towards storing and displaying the fractions in
their initial, non-reduced state and throwing an exception if a zero
denominator is encountered (which would also cover the case 0/0). Note however
that the zero denominator check is not straightforward as it is possible to
populate the rational array after the TIFFField is created and this is actually
done in the TIFF ImageWriter. Because of this the zero denominator check might
be infeasible. Also note that removing the existing fractional reduction {k*q,
k} —> {q, 1} from getValueAsString() would require changing the API
documentation hence a CCC request. The zero denominator check if implemented
would also require an API update.
Thanks,
Brian
On Nov 14, 2016, at 7:02 AM, Alexander Stepanov
<alexander.v.stepa...@oracle.com> wrote:
> P.S. please let me know if for some purposes the fractions should be stored
> in the initial (non-reduced) state. at a 1st glance it is not required, but
> maybe I'm wrong.
>
> If this is the case, then only some part of the changes should probably be
> applied:
> 1. remove needless reduction in getValueAsString()
> 2. check the sign for the unsigned fractions
> 3. forbid null denominators (?)
>
> On 11/14/2016 5:30 PM, Alexander Stepanov wrote:
>> Hello,
>>
>> Could you please review the following fix
>> http://cr.openjdk.java.net/~avstepan/8152293/webrev.00/
>> for
>> https://bugs.openjdk.java.net/browse/JDK-8152293 ?
>>
>> Thanks,
>> Alexander
