Copying GPS metadata from JPG to DNG of Samsung S9

Started by Mugros, July 17, 2018, 06:21:27 PM

Previous topic - Next topic

Mugros

The DNG of the Samsung S9 doesn't seem to have any location data in them (although Google photos locates them, possibly by getting the data from the JPG). I want to copy the GPS metdata from the accompanying JPG to the DNG, but could make it work.

I found examples of how to do it with exiftool (latest version), but it doesn't work:
>exiftool -tagsfromfile %d%f.JPG  -gps:all -r -ext DNG .
Warning: [minor] Oversized SubIFD StripByteCounts (571536 bytes, but expected 142884) - ./20180715_160556.dng
Error: Error reading image data - ./20180715_160556.dng
    1 directories scanned
    0 image files updated
    1 files weren't updated due to errors

Phil Harvey

I don't have an S9 sample so I can't try this myself, but it looks like ExifTool won't write this file because there is a significant problem with the way the raw data is stored.  If you want, you can send me a sample so I can check it.  My email is philharvey66 at gmail.com

- 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 ($).

Phil Harvey

I got the file, thanks.

There is something very odd about the way the reduced-resolution image in the SubIFD is written:

exiftool -subifd:all -a ../pics/SamsungSM-G965F.dng
Subfile Type                    : Reduced-resolution image
Image Width                     : 504
Image Height                    : 378
Bits Per Sample                 : 4 2 0
Compression                     : Uncompressed
Photometric Interpretation      : YCbCr
Strip Offsets                   : 24411616
Samples Per Pixel               : 3
Rows Per Strip                  : 378
Strip Byte Counts               : 571536
Planar Configuration            : Chunky


The biggest problem is that StripByteCounts reports 571536 bytes of data at offset 24411616, but this offset is only 285768 bytes from the end of file.  So either the file is truncated or the StripByteCounts is wrong.  Probably the latter.  In either case, ExifTool won't write this file because of the risk of doing further damage.

Also, the BitsPerSample is odd.  Only 4 bits for luminance, 2 bits for blue chrominance and 0 for red.  Weird.

- Pihl
...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 ($).

Mugros

It's the same with all files I tested, same error, same values.

The only other information I can give is that Irfanview shows three low-resolution grayscale images side by side and some garbage underneath when viewing those DNGs. XnViewMP shows a very low-resolution image with very brownish colors. Adobe Camera RAW and Lightroom have no problems showing it, neither does Google Photos.

Side note, the app OpenCamera produces DNG that are readable in all programs and even have the GPS data to begin with.

Phil Harvey

Yes.  This is a bug in the Samsung (or Android?) software that wrote this DNG file.  I don't doubt that it is viewable on other apps, but ExifTool won't write it because of the risk of data loss since there is a significant error in the way the data is stored.

- 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 ($).