Support for tag PrintImageMatching 0xc4a5

[spicymatt]

First of all, thanks for your work on this important library.

Describe the bug Writing metadata in a Sony ARW file currently corrupts the file because it suppresses an important portion of metadata containing the white balance (WB) information (SR2Private). I don't know whether this bug is only present for sony systems. The level of corruption depends on the application used. Some apps won't recognize the file as a RAW, refusing to open it (Capture One, Lightroom). Some apps (Preview on mac) can handle the file, but with messed up WB. Some other apps (Affinity Photo) are doing a good job at opening and rendering the file.

This problem seems pretty old as it was reported 8 years ago, but also more recently (a few years back).

I wonder whether it was concluded that a fix would be too hard to implement since the problem is still present after all these years. Can you update me on the status and conclusions ?

To Reproduce add GPS information to a Sony ARW file using exiv2 to exhibit the issue.

When using exiftool on the original image, the following metadata section is populated:

c           : 51546
SR2 Sub IFD Length              : 56958
SR2 Sub IFD Key                 : 0x44332211
Black Level                     : 512 512 512 512
WB RGGB Levels Auto             : 2028 1024 1024 2128
WB RGGB Levels                  : 2028 1024 1024 2128
Color Matrix                    : 1406 -391 9 -42 1356 -290 22 -53 1055
WB RGB Levels Daylight          : 2324 1024 1556
WB RGB Levels Cloudy            : 2520 1024 1428
WB RGB Levels Tungsten          : 1412 1024 2800
WB RGB Levels Flash             : 2572 1024 1404
WB RGB Levels 4500K             : 2088 1024 1752
WB RGB Levels Shade             : 2788 1024 1284
WB RGB Levels Fluorescent       : 2176 1024 2256
WB RGB Levels Fluorescent P1    : 2224 1024 1688
WB RGB Levels Fluorescent P2    : 2504 1024 1468
WB RGB Levels Fluorescent M1    : 1644 1024 2784
WB RGB Levels 8500K             : 2944 1024 1216
WB RGB Levels 6000K             : 2496 1024 1444
WB RGB Levels 3200K             : 1584 1024 2428
WB RGB Levels 2500K             : 1224 1024 3372
White Level                     : 15360 15360 15360
Vignetting Corr Params          : 11 0 0 160 480 928 1568 2368 3232 4192 5216 6272 0 0 0 0 0
Chromatic Aberration Corr Params: 22 1152 1024 1024 896 896 896 896 768 640 512 384 -128 0 0 0 0 -128 -128 0 128 384 640 0 0 0 0 0 0 0 0 0 0
Distortion Corr Params          : 11 5 -1 -14 -32 -58 -89 -127 -167 -212 -258 -307 0 0 0 0 0

After writing the metadata (for example adding GPS), this section disappears and is replaced by

Warning                         : [minor] Bad format (33696) for SR2Private entry 0

I think this SR2Private section is being damaged causing the reading issue. All the camera WB info is lost causing the rendering issues.

[clanmills]

I've left that to "drift in space". This was reported on the forum and doesn't seem to have an associated issue. So, it silently dropped off the radar! https://dev.exiv2.org/boards/3/topics/3153?r=3171#message-3171

Thank You for your analysis. It sounds like the SubIFD is not being dealt with correctly when the file is updated. I have the knowledge of both image formats and Exiv2 architecture to fix this, as I am currently working on a book which I want to finish this year. https://clanmills.com/exiv2/book/

It would be helpful to have a solid test case, which would be an ARW file and an exact command that demonstrates the damage being done. Any supporting ExifTool evidence is helpful, however not essential. I promise to investigate, however I don't promise to fix this as my priority is to finish the book and retire by my 70th birthday on 2021-01-18.

[clanmills]

I rediscovered this case which seems identical to yours. https://dev.exiv2.org/boards/3/topics/1347?r=1348#message-1348

The test file DSC00608.ARW is no longer available. So the trail runs cold. It hasn't been stored in my collection of 7000+ test files:

1072 rmills@rmillsmm-local:/Users/Shared/Jenkins/Home/userContent/testfiles $ find . -type f | wc
   7370    7381  250287
1073 rmills@rmillsmm-local:/Users/Shared/Jenkins/Home/userContent/testfiles $ 1073 rmills@rmillsmm-local:/Users/Shared/Jenkins/Home/userContent/testfiles $ find . -type f | grep 608
./Phils/SonyEricsson/SonyK608i.jpg
./Phils/Samsung/SamsungSGH-G608.jpg
./Phils/DXG/DXG_DSC608.jpg
./Phils/Sony/SonyDCR-DVD608E.jpg
1074 rmills@rmillsmm-local:/Users/Shared/Jenkins/Home/userContent/testfiles $ 

[clanmills]

I'm mistaken. I have the fine DSC00608.ARW. I'll investigate on Monday.

[clanmills]

I have investigated this. This is a tough issue and I don't have the time to deliver a fix.

See: https://dev.exiv2.org/boards/3/topics/1347?r=1348#message-1348 PrintImageMatching tag 0xc4a5 is in your file as UNDEFINED metadata. I can examine the tag with the tvisitor application discussed in my book.

1131 rmills@rmillsmm-local:~/temp $ tvisitor -pRU DSC00608.ARW | grep 0xc4a
     214 | 0xc4a5 Exif.Image.0xc4a5            | UNDEFINED |      106 |       334 | PrintIM_0300__._._.___._"___..____.. +++
1132 rmills@rmillsmm-local:~/temp $ 

However it's actually an IFD. The value of the tag is unchanged and is therefore still referencing offset 334 in the file. Sadly, the IFD has not been rewritten.

$ exiv2 -M"set Exif.GPSInfo.GPSLatitude 4/1 15/1 33/1" -M"set Exif.GPSInfo.GPSLatitudeRef N" DSC00608.ARW

If we examine DSC00608.ARW with ExifTool before/after modification by exiv2:

Before

...
Lens Model                      : E 55-210mm F4.5-6.3 OSS
PrintIM Version                 : 0300
SR2 Sub IFD Offset              : 47644
SR2 Sub IFD Length              : 29252
SR2 Sub IFD Key                 : 0x44332211
Black Level                     : 512 512 512 512
...
Subfile Type                    : Reduced-resolution image
Make                            : SONY
Camera Model Name               : NEX-6
...

After

Lens Info                       : 55-210mm f/4.5-6.3
Lens Model                      : E 55-210mm F4.5-6.3 OSS
GPS Latitude Ref                : North
PrintIM Version                 : 0300
Warning                         : [minor] Bad format (53730) for SR2Private entry 0
Subfile Type                    : Reduced-resolution image
Make                            : SONY
Camera Model Name               : NEX-6
...

It's obvious that the data "inside" the PrintImageMatching IFD has been lost.

Fixing this is non trivial. A couple of weeks ago, the following issue involving reading an IFD in a hidden embedded TIFF in a RAF (FujiRaw) surfaced and was fixed. #1402. It consumed about 40 hours to fix and add suitable code to the test harness. Exiv2 does not provide write support for RAF files. I suspect that updating the RAF file would have taken another 40 hours.

The man page for Exiv2 says that ARW is read only. Internally Exiv2 sees ARW as a Tiff file which is writeable. Exiv2 does not currently have code to correctly deal with PrintImageMatching tag 0xc4a5 for which I haven't found documentation in the TIFF-EP or DNG 1.5 Specs. So, Exiv2 is treating this file as a Tiff and doesn't have the necessary code to either decode or re-encode PrintImageMatching.

Regrettfully, this issue is too difficult to solve at this time. I will leave the issue open, however I'm unassigning myself and releasing this from the v0.27.4 Milestone.

[clanmills]

https://www.loc.gov/preservation/digital/formats/content/tiff_tags.shtml

[mlmilliman]

I have several files that are Sony ARW format where I wrote to the ITPC and now the file is corrupted in this way. Is there a way to remove the corrupted data or IFD and replace it with data from a similar photo? I don't care if there is some loss of EXIF data at this point. I do not want to lose my image.

[clanmills]

I'm going to set this milestone: v1.00 and hope that a Team Member will accept the challenge.