The serialization of double typed geographical
coordinates to DMS system supported by the exif
standards was previously truncated without need.
The previous code truncated the seconds part of
the coordinate to a fraction with denominator
equal to 1 causing a bug on the deserialization
when the test for the coordinate to be serialized
was more precise.
This patch applies a 10E6 multiplier to the numerator
equal to the denominator of the rational number.
Eg. Latitude = 89.5688643 Serialization
DMS Old code = 89/1 deg, 34/1 min, 7/1 sec
DMS New code = 89/1 deg, 34/1 min, 79114800UL/10000000UL
Deserialization
DMS Old code = 89.5686111111
DMS New code = 89.5688643
The new test tries to serialize a higher precision
coordinate.
The types of the coordinates are also guint32 instead
of gint like previously. guint32 is the type of the
fraction components in the exif.
https://bugzilla.gnome.org/show_bug.cgi?id=767537
This tag match the EXIF_TAG_FOCAL_LENGTH_IN_35_MM_FILM exif tag and is
stored on a short. Hence there is a precision loss compared to the
GstTag which is a double value.
https://bugzilla.gnome.org/show_bug.cgi?id=753930
Bypass g_convert/iconv if there's nothing to convert. That way,
conversion won't fail on systems where iconv doesn't support
converting utf-8 to latin1 and there's nothing to convert.
https://bugzilla.gnome.org/show_bug.cgi?id=723252
When the payload for an Exif tag is less than or equal to 4 bytes,
the data is simply put into the offset field. Fix writing these
kinds of payloads on big endian systems (and possibly also on
little endian systems). The caller will have already formatted
the bytes in memory according to the writer's endianness, so just
write out the bytes as they are in this case. Fixes tags unit test
on big endian systems.
When using g_convert, we should only pass the length
of the string content (without the \0) as g_convert will
only parse the real contents when changing formats. Including
the \0 causes it to add another \0, increasing the string
size when not needed.
For example, when writting a North geo location ref entry, that should
be a string with a single N letter, it would write:
"N\0\0", causing the string to have size 3, instead of 2 as expected.
In our case, we can pass -1 and let g_convert calculate the strlen as
we don't use the length anywhere else.
This fixes jifmux's tests on gst-plugins-bad.
Exif uses tags like image-vertical-ppi or image-horizontal-ppi which are
registered in gst_tag_register_musicbrainz_tags(), but neither GstExifReader
nor GstExifWriter register them.
https://bugzilla.gnome.org/show_bug.cgi?id=648459
Adds a tag to inform what mode was used by a camera to calculate
the picture capturing exposure
Also adds mapping to exif and tests
API: GST_TAG_CAPTURING_METERING_MODE
https://bugzilla.gnome.org/show_bug.cgi?id=631773
Adds new tag for tagging sharpness processing used
when capturing an image. Also maps it in the exif
tags.
Tests included.
API: GST_TAG_CAPTURING_SHARPNESS
https://bugzilla.gnome.org/show_bug.cgi?id=631773
