Note 8 Live focus Image

Started by tonE, March 15, 2018, 07:10:55 PM

Previous topic - Next topic

tonE

I've been able to extract the depth map from a Samsung Note 8 "Live Focus" image. It uses this depth map to produce refocussed images - Background Bokeh effects. I ran into an odd situation. I have some images that have the byte order switched from the usable [Little-endian (Intel, II)] to unusable [Big-endian (Motorola, MM)].  The Maker info indicates  EmbeddedImageName of DualShot_1 and DualShot_2  (2)embedded images. The standard method for changing byte order
exiftool -all= -tagsfromfile 094326.jpg -all:all -unsafe -exifbyteorder=little-endian 094326.jpg

changes the byte order and only works on one image, the color image. The Depth map is not exported and saved  If the Byte Order can't be changed is there a way to extract the  DualShot_1 and DualShot_2 embedded images to separate files?

Phil Harvey

Send me the file in question and I'll take a look.  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

You can extract both embedded images like this:

exiftool -embeddedimage -b -W %f_embedded%.nc.jpg FILE

This works for both the good and bad images you sent.

The big differences I see are that the bad image is missing an awful lot of EXIF, including the maker notes and 48 kB of unknown data in the trailer.  I used the -htmldump feature to look at the files in more detail.

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

tonE

Phil thanks. Looks like it extracted only the (embedded?) wide angle image and not the actual depth map. I'll send the separated files.

Phil Harvey

Yes, I didn't see a depth map.  Perhaps this is the unknown 48 kB in the trailer, which didn't look to be in any image format I recognized, and isn't extracted by ExifTool.  It could be just raw depth information maybe.  I'll take a closer look when I get a chance.

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

tonE

Phil, it would be a great Exiftool fix for what appears to be a Samsung Note 8 camera software problem. While the two photos were taken quickly back to back in "Live Focus", and each shot still supported in-camera, post-processing depth of field (suggesting that each set had a depth map); there was an error writing the files as only the first was correctly written to file with little-endian byte order. I may write Arcsoft on the matter. I have your tool to thank for revealing the use of Arcsofts "Dual camRefocus" routine in the _094326_jpg image. I can retrieve a usable depth map with the wide&tele images and or a depth map od each to produce a multiview 3D effect...just a pain going through all the steps. Let you know what I find out.

Phil Harvey

Ah.  Looking at the trailer in more detail I can see the depth map.  It is unformatted raw data.  I will look into extracting this.

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

tonE

"It is unformatted raw data." I assume this is in reference to the '094326.jpg'. So that may just be the computational data and not image data? A sort of chicken and the egg problem which came first the depth data or the depth image?

Phil Harvey

I don't have all the files with me right now, and I don't remember the file names, but the next version of ExifTool will generate a TIFF-format depth image which is equivalent to the JPEG-format one you sent by email with a name ending in _r.jpg.  It will do this by putting a TIFF wrapper around the raw depth data that I found in the full good .jpg you sent.

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

tonE

Phil, so to summarize, both images have RAW image data. The "bad" file  [_094326.jpg] is corrupt in that either the byte order is wrong, it is untagged or both, but it appears to be an EXIF tool fixable matter (given a possible rewrite for this particular issue). How incredible is that!!! I have quite a few files that may have the same situation; I just haven't gotten around to working with them. Also, the issue seems to be a shot-time random event.

Phil Harvey

Hi TonE,

The biggest problem I see with the bad image is that it is missing the makernotes and make/model tags.  Without these, it is the software may not be able to recognize the image, even if it has the depth map.  You can try copying them from a good file to see if that helps.  See FAQ 8 for help with this.

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

tonE

 I will definitely try that. I am a noob with Exiftool so it may take a little headbanging but I'll give it an honest try. Thanks for making it easy to work with your tool.

FMax

#12
I've inspected Samsung A6+ "Live Focus" images in ExifTool and ExifToolGUI and made some tests with them.

You can generate a file with only result image (partly blurred one) this way:
exiftool -trailer:all= -o %f_blurred%.nc.jpg FILE

You can extract the original RGB image this way, as Phil has mentioned above:
exiftool -embeddedimage -b -W %f_embedded%.nc.jpg FILE

And you can extract the depth map this way:
exiftool -DepthMapData -b -W %f_depth%.nc.pgm FILE
Then open this file in Notepad++ (or any similar editor) and add (just in plain ASCII) the following 3 lines in the beginning of the file:
P5
920 690
255

P5 specifies the file to be in Binary Portable GrayMap format (https://en.wikipedia.org/wiki/Netpbm_format#File_format_description).
920 690 are depth map width and height, respectively. You can find them this way:
exiftool -DepthMapWidth -DepthMapHeight FILE
255 is the maximum gray value.

Note that depth maps exported this way are in its original orientation and are not affected by matadata Orientation tag.
To view PGM files and rotate them you can use XnView, for example.

Phil Harvey

Thanks for the post.

Why are you using PGM?  ExifTool has a Composite DepthMapTiff tag to produce a TIFF for you.

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

FMax

Thank you, Phil.
That looks like a more elegant way of solving the problem. But how do you use it? Could you please share an example of a command-line call?