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?
Send me the file in question and I'll take a look. My email is philharvey66 at gmail.com
- Phil
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
Phil thanks. Looks like it extracted only the (embedded?) wide angle image and not the actual depth map. I'll send the separated files.
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
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.
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
"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?
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
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.
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 (https://exiftool.org/faq.html#Q8) for help with this.
- Phil
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.
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 (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.
Thanks for the post.
Why are you using PGM? ExifTool has a Composite DepthMapTiff tag to produce a TIFF for you.
- Phil
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?
exiftool -DepthMapTiff -b -W %f_depth%.nc.tif FILE
That's awesome. Thank you!
New Samsung Galaxy smartphones have slightly different approaches.
Galaxy S10+ doesn't store depth map at all, but stores both photographs: from regular and wide-angle lens cameras.
And Galaxy A80 stores both photographs (from regular and wide-angle lens cameras) as well as depth map. The depth map is stored under a new tag, which falls into unknown (https://exiftool.org/exiftool_pod.html#u--unknown) category, so it can be extracted with the following command:
exiftool -SamsungTrailer_0x0ab1 -U -b -W %f_depth%.nc.pgm FILEThen 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
1060 795
255
P5 specifies the file to be in Binary Portable GrayMap format (https://en.wikipedia.org/wiki/Netpbm_format#File_format_description (https://en.wikipedia.org/wiki/Netpbm_format#File_format_description)).
1060 795 are depth map width and height, respectively.
255 is the maximum gray value.
Quote from: FMax on November 17, 2018, 09:33:44 AM
Note that depth maps exported this way are in its original orientation and are not affected by metadata Orientation tag.
To view PGM files and rotate them you can use XnView, for example.
Tag name (
-SamsungTrailer_0x0ab1) can be found this way:
exiftool -args -U FILEAnd depth map width and height (
1060 and
795) can likely be found in DualShot_Meta_Info or DualShot_Extra_Info, or calculated:
x = ⌊√(
s/(
ab))⌋, where
s is PGM file size (
843760 in case of Galaxy A80),
a is aspect ratio width units (
4 in case of A80),
b is aspect ratio width units (
3 in case of A80).
w =
axh =
bx
Quote from: FMax on July 01, 2019, 12:38:14 PM
And Galaxy A80 stores both photographs (from regular and wide-angle lens cameras) as well as depth map. The depth map is stored under a new tag[...]
Could you possibly send me a pair of these files (philharvey66 at gmail.com).
- Phil
Sure, just sent.
Thanks, but I meant to send a live-focus pair. Not two different images.
- Phil
By live-focus pair do you mean two photographs from regular and wide-angle lens cameras? Those are stored inside of each JPEG file I've sent you: 2 images extractable with -embeddedimage tag.
Ah, OK. I misunderstood. Thanks.
I have patched the most recent version of ExifTool to extract the DepthMapWidth/Height from these files.
- Phil
That's fast :) Works great. Thank you!
A note about extracting depth maps from Nokia 9 PureView. This can be done with the following command:
exiftool -DepthImage -b -W %f_depth%.nc.jpg FILE