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]
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. |
|
Main JPG image displayed here at 5% width (1/436 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
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.