I can`t open panorama photos from my samsung s7

[elredm12552173]

I can`t open panorama photos ( jpg) from my samsung s7. the error message is in english ( Lightroom has encountered problems reading this photo. You will not be able to make adjustments to the photo.) or german ( Beim Lesen dieses Fotos ist in Lightroom ein Problem aufgetreten. Sie können keine Änderungen am Foto vornehmen.).

I can open the pictures in preview mac / photomatixpro / affinity photo without any problems.

[johnrellis]

Please do Help > System Info and report the exact version of LR you are running.  I suggest you upload a sample panorama to Dropbox (or similar) and post the link here.  That will help us troubleshoot what might be going wrong.

[justin_ss]

Was this ever resolved? I'm having the same problem... I just tried to start editing photos that I've taken with my Galaxy S7 in panorama mode and Lightroom is telling me that I can't edit any of them, and it's also not showing previews. I just updated to the latest version from CC. I have no issues opening the same panorama in Photoshop.

[johnrellis]

Please upload one of the problem photos to Dropbox (or similar) and post the link here.  That will enable us to start troubleshooting.

[justin_ss]

Hi,

Thanks for the quick response. Here is a link to a Google Drive folder with (5) sample images, and the Error Screen:

https://drive.google.com/folderview?id=0BzemtBqLMjkHZ3JJT0h2eUFvbEU&usp=sharing

Sample Photos

Below is a copy of the System Information from Lightroom. I have no issues with any "normal" Galaxy S7 photos, and I've always been able to edit panoramas from my Galaxy S5. Thanks.

Lightroom version: CC 2015.5 [ 1067055 ]

License: Creative Cloud

Operating system: Windows 10

Version: 10.0

Application architecture: x64

System architecture: x64

Logical processor count: 4

Processor speed: 2.3 GHz

Built-in memory: 16298.4 MB

Real memory available to Lightroom: 16298.4 MB

Real memory used by Lightroom: 491.2 MB (3.0%)

Virtual memory used by Lightroom: 433.4 MB

Memory cache size: 304.2 MB

Maximum thread count used by Camera Raw: 4

Camera Raw SIMD optimization: SSE2,AVX,AVX2

System DPI setting: 120 DPI

Desktop composition enabled: Yes

Displays: 1) 1920x1080

Input types: Multitouch: Yes, Integrated touch: Yes, Integrated pen: No, External touch: No, External pen: No, Keyboard: No

Graphics Processor Info:

Intel(R) HD Graphics 5500

Check OpenGL support: Passed

Vendor: Intel

Version: 3.3.0 - Build 20.19.15.4331

Renderer: Intel(R) HD Graphics 5500

LanguageVersion: 3.30 - Build 20.19.15.4331

Application folder: C:\Program Files\Adobe\Adobe Lightroom

Library Path: C:\Users\Justin\Pictures\Jpgs\+Lightroom Catalogs\Master Catalog\Master Catalog-2-2.lrcat

Settings Folder: C:\Users\Justin\AppData\Roaming\Adobe\Lightroom

Installed Plugins:

1) Canon Tether Plugin

2) Facebook

3) Flickr

4) Leica Tether Plugin

5) Nikon Tether Plugin

Config.lua flags: None

Adapter #1: Vendor : 8086

  Device : 1616

  Subsystem : 6951028

  Revision : 9

  Video Memory : 128

Adapter #2: Vendor : 1002

  Device : 6604

  Subsystem : 6951028

  Revision : 0

  Video Memory : feb

Adapter #3: Vendor : 1414

  Device : 8c

  Subsystem : 0

  Revision : 0

  Video Memory : 0

AudioDeviceIOBlockSize: 1024

AudioDeviceName: Speakers / Headphones (Realtek High Definition Audio)

AudioDeviceNumberOfChannels: 2

AudioDeviceSampleRate: 44100

Build: LR5x102

Direct2DEnabled: false

GPUDevice: not available

OGLEnabled: true

[johnrellis]

The sample files have the same issue in my LR CC 2015.5 / OS X 10.11.4.  I'll put them under the microscope to see what might going on.

[johnrellis]

The samples all appear to have been modified by Adobe Photoshop? 5.0.  Can you post a sample taken straight from the camera?  That might make the troubleshooting a little simpler.

[justin_ss]

No, these photos haven't been edited at all. The photos were taken on my Galaxy S7, then synced directly to my desktop through a Dropbox syncing app on my phone. The Dropbox sync app (Dropsync) syncs the photos directly to a dropbox account from my phone, which then copies the files directly to my computer. These should be exact copies of the original files on my phone with no alterations. Also, I've always used this method previously and have never had any issues.

Of course, the reason is may be saying that is because I tried to add them to my Lightroom Catalog (that's where the error screenshot came from), so it's possible Lightroom modified the file in some way when it attempted to add it, but I don't think Lightroom is supposed to modify the originals in any way, right?

I will try to resync the original files and see if that helps.

[justin_ss]

I synced new photos which should've eliminated any possibility that the photos were tampered with and had an interesting result. I took two panoramas yesterday, exactly 25 seconds apart, with the exact same settings on my phone, meaning the photos should be identical. I synced them at the same time (just now) and imported them into Lightroom at the same time (just now). However, one photo displayed correctly in Lightroom and the other did not.

Here's the first photo, which Lightroom recognizes correctly:

20160416_105125.jpg - Google Drive

Here's the second photo taken 25 seconds later that is giving the same issue as before, it is unreadable by Lightroom:

20160416_105150.jpg - Google Drive

Thanks for looking into this. I really need these photos for a website I'm creating.

[johnrellis]

Exiftool is showing abmormalities in the file that LR can't read. I'll spend some more time trying to understand the issue later tonight. At a minimum, it appears that Samsung is appending non-standard information to the file.

[ssprengel]

Of these two, the one that works, ending in 25.jpg, has a thumbnail that is upside-down and has a 180-degree rotation flag set; whereas the one that doesn't work, ending in 50.jpg, has a normal thumbnail and no rotation indicated.

So maybe the direction of the drag from right-to-left or from left-to-right makes a difference.  This should be easy to experimentally verify.

The panorama also works if you open and save it, again, with Photoshop, which may strip or at least rewrite some of the information.

http://regex.info/exif.cgi

Jeffrey's Image Metadata Viewer

[CLEAR IMAGE]

From Web From File

Image URL:

From Web From File

File name:

Basic Image Information

Target file:	20160416_105125_ok.jpg
Camera:	samsung SM-G930T
Lens:	4.2 mm (Max aperture f/1.7) (shot wide open)
Exposure:	Auto exposure, Program AE, f/1.7
Flash:	Off, Did not fire
Date:	April 16, 2016   10:51:25AM  (timezone not specified) (1 day, 5 hours, 42 seconds ago, assuming image timezone of US Pacific)
Location:	Latitude/longitude: 33° 25' 7" North,   117° 37' 17" West ( 33.418611, -117.621389 ) Location guessed from coordinates: San Clemente Pier, San Clemente, CA 92672, USA Map via embedded coordinates at: Google, Yahoo, WikiMapia, OpenStreetMap, Bing (also see the Google Maps pane below)
File:	9,392 × 2,208 JPEG (20.7 megapixels)   19,771,210 bytes (18.9 megabytes)
Color Encoding:	WARNING: Color space tagged as sRGB, without an embedded color profile. Windows and Mac browsers and apps treat the colors randomly. Images for the web are most widely viewable when in the sRGB color space and with an embedded color profile. See my Introduction to Digital-Image Color Spaces for more information.

Main JPG image displayed here at 5% width (¹/₄₃₆ the area of the original)

Click image to isolate; click this text to show histogram

---

Here's the full data:

EXIF — this group of metadata is encoded in 656 bytes (0.6k)

Make	samsung
Camera Model Name	SM-G930T
Modify Date	2016:04:16 10:51:25 1 day, 5 hours, 42 seconds ago
Y Cb Cr Positioning	Centered
F Number	1.70
Exposure Program	Program AE
Exif Version	0220
Date/Time Original	2016:04:16 10:51:25 1 day, 5 hours, 42 seconds ago
Create Date	2016:04:16 10:51:25 1 day, 5 hours, 42 seconds ago
Image Size	9,392 × 2,208
Software	G930TUVU2APC8
Max Aperture Value	1.7
Metering Mode	Average
Flash	Off, Did not fire
Focal Length	4.2 mm
Color Space	sRGB
Exposure Mode	Auto
White Balance	Auto
Focal Length In 35mm Format	26 mm
Scene Capture Type	Landscape
Image Unique ID	C
GPS Latitude Ref	North
GPS Latitude	33.418611 degrees
GPS Longitude Ref	West
GPS Longitude	117.621389 degrees
Image Width	512
Image Height	384
Orientation	Rotate 180
Resolution	72 pixels/inch

MakerNotes

Samsung Trailer 0x0201 Name	Motion_Panorama_MP4_000
Samsung Trailer 0x0201	(12,399,351 bytes binary data)
Samsung Trailer 0x08e1 Name	Motion_Panorama_Info
Samsung Trailer 0x08e1	(48,064 bytes binary data)
Samsung Trailer 0x0a01 Name	Image_UTC_Data
Samsung Trailer 0x0a01	(13 bytes binary data)
Samsung Trailer 0x08e0 Name	Panorama_Shot_Info
Samsung Trailer 0x08e0	(12 bytes binary data)

APP14

DCT Encode Version	256
APP14 Flags 0	(none)
APP14 Flags 1	(none)
Color Transform	YCbCr

JFIF

JFIF Version	1.01
Resolution	59 pixels/cm

File — basic information derived from the file.

File Type	JPEG
File Type Extension	jpg
MIME Type	image/jpeg
Exif Byte Order	Little-endian (Intel, II)
Comment	File written by Adobe Photoshop%a8 5.0
Encoding Process	Baseline DCT, Huffman coding
Bits Per Sample	8
Color Components	3
File Size	19 MB
Image Size	9,392 × 2,208
Y Cb Cr Sub Sampling	YCbCr4:2:0 (2 2)

Composite
This block of data is computed based upon other items. Some of it may be wildly incorrect, especially if the image has been resized.

GPS Latitude	33.418611 degrees N
GPS Longitude	117.621389 degrees W
Aperture	1.70
GPS Position	33.418611 degrees N, 117.621389 degrees W
Megapixels	20.7
Scale Factor To 35 mm Equivalent	6.2
<a class='quiet' href='http: en.wikipedia.org="" wiki="" circle_of_confusion?="">Circle Of Confusion	0.005 mm
Field Of View	69.4 deg
Focal Length	4.2 mm (35 mm equivalent: 26.0 mm)
<a class='quiet' href='http: en.wikipedia.org="" wiki="" hyperfocal_distance?="">Hyperfocal Distance	2.14 m

---

This application uses Phil Harvey's most excellent Image::ExifTool library, version 10.10. Histograms created with ImageMagick.
Jeffrey last modifed this viewer on March 13, 2016.
Photos and data viewed with this service are not shared with anyone else, nor are they saved beyond the temporary period needed for the service to function

[johnrellis · Accepted solution]

The unreadable image (20160416_105150.jpg) is not encoded in conformance with the industry standard for JPEGs.  Besides LR, some programs can't read the image, some can.  Of the ones I've tested:

Can't read: Exiftool, FastPictureViewer (Win), Firefox (Mac), Gimp 2.8 (Mac), Lattice (Mac), Lightroom CC 2015.5 (Mac)

Can read: Adobe Photoshop CC 2015 (Mac), ColorSync Utility (Mac), Chrome (Mac), Image Viewer (Mac), IrfanView (Win), Paint (Win), Paintbrush (Mac), Photo Gallery (Win), Photos (Win), Photoscape X (Mac), Picasa 3.9 (Mac), Safari (Mac)

You might consider filing a bug report with Samsung.  You could file a feature request in the official Adobe feedback forum to relax LR's adherence to the standard, like many other programs do.  But I doubt that Adobe would implement the request any time soon, if at all, given that almost all camera firmware manages to properly encode JPEGs.

Here are the gory details:

A JPEG is encoded as a sequence of segments, each segment starting with a marker.  A marker consists of the byte 0xFF followed by a one-byte marker code.  In the compressed image data, any data byte equal to 0xFF should be encoded as a two-byte sequence, 0xFF 0x00.

In the unreadable image, it appears that the Samsung has "forgotten" to encode such 0xFF data bytes.  Running "exiftool -v4" shows numerous spurious segments appearing within the image data:

JPEG marker 0x98 (27076 bytes):

JPEG SOF6 (1564 bytes):

JPEG marker 0x02 (30962 bytes):

JPEG marker 0xbd (872 bytes):

JPEG marker 0x4c (44612 bytes):

JPEG JPG3 (65387 bytes):

When a program that strictly conforms to the standard encounters such a spurious segment marker (e.g. 0xFF 0x98), it decides the image is invalid. But it appears that many programs don't strictly adhere to the standard.  They ignore these spurious segment markers, treating them as data bytes and "correcting" for Samsung's bug.  The Samsung engineers probably tested their code with such a program.

[johnrellis]

No, these photos haven't been edited at all.

Turns out that Samsung is inserting a spurious COM (comment) segment into its JPEGs:

JPEG COM (36 bytes): Comment = File written by Adobe Photoshop. 5.0

Pretty random on their part, and doesn't give much confidence.

[justin_ss]

Thanks johnrellis & ssprengel.

So I wonder what I should do then... Other than filing reports with Samsung and Adobe, which doesn't seem like it'll solve the problem anytime soon, what would you recommend? It's just so strange that some panoramas would work and others wouldn't, but I suppose that's the bug. Seeing as how the Galaxy S7 is new and has been such a popular phone to take photos on, either Samsung will have to correct it or Adobe will have to accomodate.

Is there any software you can think of which would batch-correct the files instead of having to open/re-save in Photoshop for each one? Or perhaps there's a batch way to do this using Bridge? I'm not an expert at these things but have some general knowledge. Or is there any third-party software you can think of?

I'll play around with the phone and see if there's a way to get the photos to correct themselves, either by changing the settings or opening/closing the file in Gallery on the phone. There's got to be some reason that some are working and others aren't.

Thanks for all of the help so far.

[ssprengel]

You can use select all the photos in Bridge then use Bridge / Tools / Photoshop / Image Processor to open and resave each photo.

You might want to change the name and put a suffix like _ps.jpg on each so as to know which ones have been through PS in case it matters at some point in the future.  I'd use the maximum quality setting of 12 and no sharpening or resizing. 

[ridelivepro]

Using this process allowed me to export workable image files.

[ridelivepro]

This still hasn't been fixed by Adobe or Samsung. I'm going to attempt the Bridge method suggested above, but overall I am disappointed that two major players haven't learned to get along.

[johnrellis]

This still hasn't been fixed by Adobe or Samsung. I'm going to attempt the Bridge method suggested above, but overall I am disappointed that two major players haven't learned to get along.

Though I've often been very critical of Adobe on these forums over the years, in this instance, I don't think it's reasonable to expect Adobe to change LR to handle files created by Samsung that don't conform to long-established, well-documented industry standards that nearly every camera manufacturer and software developer have gotten right for two decades.  My quickie testing showed at least four other widely used programs (Exiftool, FastPictureViewer, Firefox, and Gimp) also choked on the files.

[Coreythomasburns]

I have had the same issue. It is not only with Photoshop or Lightroom, it is also with Snapseed. It is the onboard S7 camera and how it writes the file. I have found two resolutions: Use Google camera to take panoramic. This will write the files properly but unless you are really steady, you will get blurry segments. I decided to use Pixlr, a free editing app. Simply open it in this app and perform no adjustments, just save it. The new file is written properly for all editing apps. I have noticed a reduction in the width and height from the original file though and this is from pictures taken without motion on which will produce a larger image. Good luck to all! Hopefully Samsung will fix this problem.

[bcyrill]

I wrote a simple python script that fixes the jpg files without requiring any editing / loosing of the contained data. The script can be found here as a Gist on GitHub.

The panoramic images created with the Samsung Galaxy S7 camera app are missing the EOI (End of Image) marker of the JPEG standard. In addition the files contain a trailer with additional Samsung specific data. E.g. the panoramic photos also contain a MP4 video file of the recorded panorama. The script detects this additional data, determines if the EOI marker exists before it and injects the marker if it is missing. It then writes the updated data as a new file with the suffix "_pano.jpg". This file can then be handled by LR or any other jpg reader.

Note: The script also allows to dump the Samsung data using the following syntax: "python fix_eoi.py file.jpg dump"

[siobhanp18048166]

Can you tell me how I go about applying that script to my photos on a Mac please?

[Dansky01]

Thank you, bcyrill.  I would like to try this, but am not sure how to do so on a windows 7 system.  Can you help?

Many thanks for your script.

[AhamB]

Old thread, but this issue is still there with newer Samsung models (S9).
What I did for Windows 10:
1. Install WinPython (make sure the environment variables are set - https://www.wikihow.com/Use-Windows-Command-Prompt-to-Run-a-Python-File).
2. Download the python script.
3. Run the script like this: python fix_eoi.py image.jpg (replacing the filename of your image).
I hope this helps. There is probably an easier way, but this works for me.

[adkcamper]

I have the same issue.  I installed the Google camera app on my Galaxy S7 and found the panorama shots taken with this app can be read in Lightroom - so guess I'll just switch camera apps...

[mike0scar]

I had the same issue and it was because the panorama's were taken with the new 'motion panorama' setting on the phone. This basically creates almost a video like file as the panorama is animated when viewed on the phone. All I did was plug the phone into my pc and browse to the panorama in question. I then opened it in a basic image viewer program (in my case Faststone Image Viewer) and then just did a 'save as..' and saved it as a normal jpg image. Will work fine with Lightroom then. Hope it helps.