ExifInterface object can be created with a unsupported file format.
If saveAttribute is called with an unsupported file format, ExifInterface
makes the file corrupted. This CL prevents those cases by throwing
an exception before making any change on the file.
Bug: 30936376
Change-Id: I115a42601c774062485974042464abb0d65c35e9
(cherry picked from commit a8f9a075b1)
This CL makes ExifInterface store the tag values as the original forms
and the format validiation is added that compares the given value and
the data format specificed in EXIF specification in order to keep the
valid tag values only.
Bug: 27583378, Bug: 27614052, Bug: 28075709
Change-Id: If60bbddefe74c4b87b4ce64b5fc79e467e36a5b9
Replaces deprecated constants with newly added constants in the actual
implementation.
Bug: 27932489
Change-Id: Id54236a05127cd7ce3bf0668c002635fb86489a9
Previously ExifInterface saved its tags in the all possible IFD tags via
setAttribute() method even it already knew the right IFD group for those
tags. In this CL, it introduces updateAttribute() and removeAttribute()
methods in order to maintain the internal IFD tags and its values
according to its original EXIF saving states in the given JPEG file.
Bug: 27583378
Change-Id: Ie49163c8c9bdd38b575ccd76938879ccddcd547b
When saving attributes(that it writes JPEG again.), now ExifInterface
generates some uncessary pointer tags which refer to an empty EXIF IFD
group, that makes a warning message by ExifInterface when reading again,
which warns that the value of the pointer tag pointing to is invalid.
Bug: 27583378
Change-Id: Id0170c5644541565c98fe4978284098e6664c395
- In case of giving an argument of the image file name or descriptor,
we created a InputStream at the inside of ExifInterface, close them
properly.
- Developers should take care of closing input streams when they use
input streams since they made those input streams.
Bug: 27636804
Change-Id: I9a3a75b1b55dcb2718a60e14814a04cad939d22c
- Give more explanations on dealing with files failed to process.
- Log and return immediately when handling lost JPEG files.
- Minor fixes in logging.
Bug: 27583378, Bug: 27587980
Change-Id: Id9a3d137e5f173fa0e6313402e5dc482a5efd57c
This CL makes ExifInterface determine the data format of rational
numbers and the values which include several components for exif entry
correctly.
Bug: 27614052
Change-Id: Ic3ea64889fad06ef5f636e4635ab7803a9c9ae29
In JPEG, an APP1 section can contain EXIF or XMP. The old code throws an
Exception when XMP APP1 segment is showns.
Bug: 27580432
Change-Id: If42197ea0c33ec4446302c969b42afd3d4b4e3c3
Some JPEG images generated by various camera vendors have wrong offsets
and invalid numbers for indicating the size of components. Instead of
throwing exceptions, this CL makes Exifinterface ignore these cases to
read the information without losing contents already parsed.
Bug: 27583378
Change-Id: Ie8ee0bf49283ef519f4f31c5b8ba78ce3f82fe92
In order to maintain compatibility with the old versions of
ExifInterface, non-JPEG image files, for instance, PNG, GIF and so on,
need to be handled by generating an empty result rather than throwing
an exception in the constructor. And corrupted JPG files also should be
handled in the same way.
Bug: 27587980
Change-Id: If33b63c683bfb672999d1abd370a8edf29932ac1
One image can have multiple image file directories, which stores the
attributes of the image, in Exif specification to save metadata.
In the old version, the all attributes from several image file
directories were combined in a one hash map eventually and were served
without distinction of the original IFD group.
In order to keep the original data as much as possible, it loads/saves
the attributes based on the original IFD group internally.
Bug: 26044456, Bug: 11224701
Change-Id: I416e4e79fd47461c9aa83ce13591ed1a5d42f26e
The readExifEntry method has raised an unnessary EOFException on reading
an non-ASCII byte array.
Bug: 27484747
Change-Id: I19371e0eed25770929f50b3ca25f249c50113925
And also the following things are included:
- Remove mInputStream.
- Update javadoc accordingly.
Bug: 11224701
Change-Id: I30b4c29ac800ae396fca8f6b2c2c0f68028a44b3
This CL depends on piex (github.com/google/piex),
which is owned by Google Photos's RAW team.
piex is capable of reading EXIF data that contains
metadata, and finding the positions in an image of
thumbnail and preview images from RAW images.
piex supports DNG, CR2, NEF, NRW, ARW, RW2, ORF
and RAF image file formats.
ExifInterface gets thumbnail and metadata information
from the above RAW image formats via piex.
Bug: 26177215
Change-Id: I529f8032bcb2a9d3d9e857ff1365a26a4f040066
Although all zero (0000:00:00) is valid time, in most cases it means
that value is not present. According to http://www.exiv2.org/Exif2-2.PDF
in such case those values should be omitted, however
some cameras set them to 0 anyway. With this commit such timestamps
will be treated as they were empty.
Change-Id: I9c762b1fa04ea6bf9c0fba9e2459a20430c71c90
Adds new ExifInterface method to extract the thumbnail range from
a larger image file, and use that to return an AssetFileDescriptor.
When decoding an AssetFileDescriptor thumbnail with offsets, read out
the raw data entirely, since Skia uses lseek() aggressively.
Bug: 10412208
Change-Id: I7906cdf82c0c3794cec7043c801a86f66efeb143
Changed degrees and minutes of geotag data into double to avoid
data loss during cast.
Also improved error handling if geotag data can't be parsed.
bug:3381761
Change-Id: I864843c7fc699fe81e6acba801fe46d10a01925b
