Preserve Ratios/Hex values of EXIF data when modified

Started by goproer, October 27, 2012, 03:59:01 PM

Previous topic - Next topic

goproer

Hello,

After some research I found a solution for converting (semi) broken GoPro HD Hero 2 JPGs (Motorola big endia format) to correct and readable EXIF format. Therefore I'm using the following command line:
exiftool -P -all= -tagsfromfile @ -all:all -unsafe -exifbyteorder=little-endian *.jpg

Works well so far except one problem: Some values (especially ratios) are not the same. Is it possible to write exactly the same values to the newly written file (e.g. use the same hex values).
If not, any plans to implement such a feature.

Example Image:
http://caverpilot.com/wp-content/uploads/2012/09/GOPR0677.jpg

BTW: Does one know whether ASCII strings are 0 terminated?

Thank you.

goproer

Phil Harvey

Quote from: goproer on October 27, 2012, 03:59:01 PM
Some values (especially ratios) are not the same. Is it possible to write exactly the same values to the newly written file (e.g. use the same hex values).
If not, any plans to implement such a feature.

The solution is not easy.  Read here.

QuoteBTW: Does one know whether ASCII strings are 0 terminated?

In EXIF they are.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

goproer

Quote from: Phil Harvey on October 27, 2012, 06:23:01 PM
Quote from: goproer on October 27, 2012, 03:59:01 PMBTW: Does one know whether ASCII strings are 0 terminated?

In EXIF they are.

- Phil

Ok, had a look at the spec: The final byte is terminated with NULL.

EXIF of the Go Pro HD Hero 2 camera looks like: String is e.g. 24 bytes long as from EXIF, but terminates with 0x00 at e.g. 12th byte. With the definition above a lot of programs display the whole string and not the 0 terminated string (e.g. Irfan View) but I think they do it right as the final byte should be NULL terminated. But I guess NULLs should not be in the middle of the string (is it stated somewhere in the spec?)

exiftool doesn't handle it correct as from the specification as far as I read it as the string is terminated before (maybe a switch to toggle behavior) but it works as expected to correct the IHMO wrongly logically defined EXIF information (example see link in 1st post).

But also EXIF information is also not an 7-Bit ASCII code (e.g. byte 0xB4 is included). So it's all about how to handle possibly incorrect information and fault behaviour.

goproer

Phil Harvey

The EXIF specification actually allows multiple NULL bytes in strings, and the spec for the Copyright tag uses this feature to store 2 strings.  However, other tags are defined with single strings only, and in practice I have found that some software stores garbage after the null byte, so ExifTool ignores this.

Unfortunately the EXIF specification is inadequate and/or unspecific in many areas (here are a few), and as a result different software may interpret the specification differently.  In fact, the MWG recommends allowing UTF-8 in EXIF ASCII values, which is certainly contrary to the specification, but makes up for one of its inadequacies.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).