I have restored the Macro EXIV2_TEST_VERSION in include/exiv2/version.hpp
I have added an option --version-test to exifprint.cpp to test/validate EXIV2_TEST_VERSION works as documented.
Version strings in Exiv2 v0.27 and later have a fourth digit to indicate the pre-release number of the build.
Pre-release builds should never be used for production purposes.
V803 Decreased performance. In case 'userEnd' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. futils.cpp 405
V803 Decreased performance. In case 'authEnd' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. futils.cpp 410
V803 Decreased performance. In case 'hostEnd' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. futils.cpp 428
V803 Decreased performance. In case 'e' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. epsimage.cpp 711
V803 Decreased performance. In case 'e' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. epsimage.cpp 841
V803 Decreased performance. In case 'e' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. epsimage.cpp 958
V803 Decreased performance. In case 'i' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. epsimage.cpp 855
V803 Decreased performance. In case 'it' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. jpgimage.cpp 817
V803 Decreased performance. In case 'lib' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. version.cpp 508
V803 Decreased performance. In case 'it' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. version.cpp 563
V803 Decreased performance. In case 'it' is iterator it's more effective to use prefix form of increment. Replace iterator++ with ++iterator. xmpsidecar.cpp 138
- Define STRERROR_R_CHAR_P properly on CMake and use it on futils.cpp
- We use now _GNU_SOURCE to determine which version of strerror_r to use
- strError only throws if ret==ERANGE
- Remove STRERROR_R_CHAR_P. It has been never used
- sort defines in config.h.cmake
- Remove EXV_HAVE_DECL_STRERROR_R that is not used anymore
- Remove EXV_HAVE_STRERROR. C++98 always will have it
Tags in exiv2 with the help of Phil Harvey's exiftool (see
http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/Canon.html).
Even with these changes (toward #1204 and #1205), exiv2 lags behind
exiftool in some areas of interpretation of Canon tags. Ideally, a
catch-up effort to bring the code in source: canonmn.cpp in line with
lib/Image/ExifTool/Canon.pm. v10.25 of exiftool was used as reference
for this change.
#1206 seeks to address the fact that when Canon does not have data for
certain tags, they use specific default values in those fields. These
default values need to be ignored and not displayed. This change
brings this feature to exiv2, something that already exiftool does.
With regards to implementation, the struct TagInfo in source: tags.hpp
is extended with four new fields.
The first field is a bool that if set to true (default false), denotes
that this field has ignorable default values.
The second field is the default value that needs to be ignored. This
can be of four types (String, Long, Float, Rational). These four types
were chosen as they had conversion functions in the Value class.
The third field is the comparison type (default equal_to). There are
six comparison types possible (equal_to, not_equal_to, less,
less_equal, greater, greater_equal). This is the comparison applied to
the value stored in the tag's field and the default value specified
above. For e.g. if the value in the tag Exif.CanonCs.RecordMode is -1,
then it needs to be ignored.
The fourth field is the data type (default Long). This could have been
guessed from the type of the second field, but that would necessitate
making this structure into a template calling for changes in multitude
of files.
Usage: In source: canonmn.cpp, several exif tags now have ignorable
default properties. I will list a few examples.
1. Exif.CanonCs.FocusMode: TagInfo(0x0007, "FocusMode", N_("Focus Mode"), N_("Focus mode setting"), canonCsId, makerTags, signedShort, 1, EXV_PRINT_TAG(canonCsFocusMode)),
There are no changes - i.e. this is an example of how the TagInfo
structure was being populated.
2. Exif.CanonCs.RecordMode: TagInfo(0x0009, "RecordMode", N_("Record Mode"), N_("Record mode setting"), canonCsId, makerTags, signedShort, 1, EXV_PRINT_TAG(canonCsRecordMode), true, s_1_),
Take a look at the two new arguments. The first one (true) specifies
that there is a default value that can be ignored. The second one s_1_
specifies the value (-1, in this case) to be ignored.
const UShortValue CanonMakerNote::s_1_(65535, unsignedShort); // Till bug is resolved
Note s_1_ is temporarily having the value 65535 till #1203 that causes
signedShorts to be interpreted as unsignedShorts is resolved.
3. Exif.CanonSi.TargetAperture: TagInfo(0x0004, "TargetAperture", N_("Target Aperture"), N_("Target Aperture"), canonSiId, makerTags, unsignedShort, 1, printSi0x0015, true, us0_, TagInfo::less_equal),
Note the third argument TagInfo::less_equal. This combined with the
second argument us0_ (the number 0) signifies that any values in this
tag that are less than or equal (<=) to 0 should be ignored.
4. TagInfo(0x0028, "ImageUniqueID", N_("Image Unique ID"), N_("Image Unique ID"), canonId, makerTags, asciiString, -1, printValue, true, s0x16_, TagInfo::equal_to, TagInfo::String),
The previous examples have all been of Long type. This shows a case
where the default value is a string.
const AsciiValue CanonMakerNote::s0x16_("0000000000000000");
Once these tag values have been defined, the actual mechanics of
ignoring these default values happens in Image::exifData().
Before the exifData is returned, we loop through the data, ask the
data whether it needs to be ignored (which in turn checks its
underlying tagInfo and compares it with the default value, if
specified) and if so, deletes that element.
A compile-time switch called EXV_DONT_IGNORE_UNDEFINED which when set
to a non-zero value will cause the behavior to revert back to the
original where all values are reported irregardless of the fact that
they need to be ignored.
