[OpenJDK 2D-Dev] [9] RFC JDK-8154058: [TIFF] ignoreMetadata parameter of TIFFImageReader's setInput() method affects TIFFImageReadParam in non-obvious way

[Brian Burkhalter]

Not entirely sure whether this addresses your concerns but I have an updated version of the test which seems to validate my intent with this:

http://cr.openjdk.java.net/~bpb/8154058/webrev.00/

Part of the output of this test is:

STDOUT:
ignore = true:
ImageWidth: 50
EXIF (false): false
Fax (false): false
GPS (true): true

ignore = false:
ImageWidth: 50
EXIF (true): true
Fax (true): true
GPS (true): true

In summary the behavior is that it reads everything, even tags it does not know about, it ignore == false, but it ignores everything it does not know about if ignore == true. Part of the motivation for reading everything when ignore == false is that there may be other tags out there which are proprietary and which the user wants to obtain but of which we are unaware.

One bug which is uncovered however is that the BaselineTIFFTagSet should not be allowed to be removed as in that case reading will fail entirely. I will need to file another issue to track that.

Thanks,

Brian

On Aug 17, 2016, at 11:09 AM, Phil Race <philip.race at oracle.com> wrote:

> Hi,
> 
> That all seems fine (for the case of ignoreMetaData == true).
> 
> But there may be still a bug - of some kind - uncovered by this test.
> The submitter has this case  :
> 
> ignore = false:
> EXIF: true
> Fax : true
> GPS : true 
> 
> which means that all metadata is being read .. as is the default per the docs
> on the TIFF package description. But I am wondering what the effect setting of 
> 
>  param.removeAllowedTagSet(FaxTIFFTagSet.getInstance());
> 
> should have been in this case.
> A strict reading of the spec. makes it sound like it only has any effect
> when you specify ignoreMetadata == true but I don't see the point
> of the API in that case, since you are already ignoring metadata, unless
> it is just a matter of being more clear to the reader that the latitude
> it has to read metadata anyway regardless should be tempered by
> this additional call.
> 
> But is there not also value in being able to remove the tag from
> the allowed set in the ignoreMetadata == false case ?
> 
> That seemed to be the gist of the text here :-
> >In cases where the IFD includes fields which contain
> > large amounts of data this could be very inefficient.
> > Which fields are loaded may be controlled by setting
> >which TIFF tags the reader is allowed to recognize and whether it is ignoring metadata.
> 
> eg .. "I want all metadata except Fax" ..
> 
> -phil.
> 
> On 08/12/2016 11:23 AM, Brian Burkhalter wrote:
>> Please comment at your convenience.
>> 
>> Issue: https://bugs.openjdk.java.net/browse/JDK-8154058
>> Solution:
>>         Resolve as “Not an Issue”
>> 
>> According to [1],
>> 
>> The ignoreMetadata parameter, if set to true, allows the reader to disregard any metadata encountered during the read. Subsequent calls to the getStreamMetadata and getImageMetadata methods may return null, and an IIOImage returned from readAll may return null from their getMetadata method. Setting this parameter may allow the reader to work more efficiently. The reader may choose to disregard this setting and return metadata normally. 
>> 
>> According to [2], setting ignoreMetadata has the effect of asking the reader to ignore any TIFF Fields which are not contained in any of the TIFFTagSets known to the reader. This seems to be within the scope of the specification in [1].
>> 
>> As a result of the foregoing I suggest that the issue be resolved as “Will not Fix.”
>> 
>> Thanks,
>> 
>> Brian
>> 
>> [1] http://download.java.net/java/jdk9/docs/api/javax/imageio/ImageReader.html#setInput-java.lang.Object-boolean-boolean-
>> [2] http://hg.openjdk.java.net/jdk9/client/jdk/file/d5dc0c4fb473/src/java.desktop/share/classes/javax/imageio/metadata/doc-files/tiff_metadata.html, lines 219-234
> 

-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://mail.openjdk.java.net/pipermail/2d-dev/attachments/20160823/e52622e5/attachment.html>