Partial Match happening for Jpeg Files

[saurabheights]

Hi Gray,
Since upgrading SimpleMagick to 1.10, JPEG images are getting partial matched. Is this change intentional?

Sample Images:

Also, I noticed common trait in the two image to have TIFF image data

$> file a.jpeg 
a.jpeg: JPEG image data, Exif standard: [TIFF image data, big-endian, direntries=6, software=Aviary for Android 4.4.6, orientation=[*0*], model=SM-A500G, datetime=2016:02:20 12:50:44, manufacturer=SAMSUNG], baseline, precision 8, 530x714, frames 3

$> file b.jpeg 
b.jpeg: JPEG image data, Exif standard: [TIFF image data, little-endian, direntries=0], baseline, precision 8, 1800x2400, frames 3

P.S. This is the same user as @se7en007.

[j256]

Ok I've one of the jpeg types but it looks like the ones you've posted implement a newer "recursive" magic pattern that simplemagic doesn't understand. I've added it to the tests though and documented in the TODO. See 95a3a4c

[saurabheights]

Hi, give me few minutes to analyze more. For now:-

`$ exiftool 62db360e-dc1d-11e6-9d93-1fe0f62a1e35.jpeg
ExifTool Version Number : 9.46
File Name : 62db360e-dc1d-11e6-9d93-1fe0f62a1e35.jpeg
Directory : .
File Size : 207 kB
File Modification Date/Time : 2017:01:16 18:55:52+05:30
File Access Date/Time : 2017:03:19 02:58:26+05:30
File Inode Change Date/Time : 2017:03:19 02:57:39+05:30
File Permissions : rw-rw-r--
File Type : JPEG
MIME Type : image/jpeg
Exif Byte Order : Big-endian (Motorola, MM)
Software : Aviary for Android 4.4.6
Orientation : Unknown (0)
Camera Model Name : SM-A500G
Modify Date : 2016:02:20 12:50:44
Make : SAMSUNG
JFIF Version : 1.01
Resolution Unit : None
X Resolution : 1
Y Resolution : 1
Image Width : 530
Image Height : 714
Encoding Process : Baseline DCT, Huffman coding
Bits Per Sample : 8
Color Components : 3
Y Cb Cr Sub Sampling : YCbCr4:2:0 (2 2)
Image Size : 530x714

$ file 62db360e-dc1d-11e6-9d93-1fe0f62a1e35.jpeg
62db360e-dc1d-11e6-9d93-1fe0f62a1e35.jpeg: JPEG image data, EXIF standard`

The initial few bytes of jpeg are:-

$ xxd im.jpeg | less

0000000: ffd8 ffe1 00a3 4578 6966 0000 4d4d 002a  ......Exif..MM.*
0000010: 0000 0008 0006 0131 0002 0000 0019 0000  .......1........
0000020: 0056 0112 0003 0000 0001 0000 0000 0110  .V..............
0000030: 0002 0000 000a 0000 006f 0132 0002 0000  .........o.2....
0000040: 0014 0000 0079 010f 0002 0000 0008 0000  .....y..........
0000050: 008d 8769 0004 0000 0001 0000 0095 0000  ...i............
0000060: 0000 4176 6961 7279 2066 6f72 2041 6e64  ..Aviary for And
0000070: 726f 6964 2034 2e34 2e36 0053 4d2d 4135  roid 4.4.6.SM-A5
0000080: 3030 4700 0032 3031 363a 3032 3a32 3020  00G..2016:02:20 
0000090: 3132 3a35 303a 3434 0053 414d 5355 4e47  12:50:44.SAMSUNG
00000a0: 0000 0000 0000 00ff e000 104a 4649 4600  ...........JFIF.
00000b0: 0101 0000 0100 0100 00ff db00 4300 0101  ............C...
00000c0: 0101 0101 0101 0101 0101 0101 0102 0201  ................

Reading more here and here.

@j256 : The second link states:-

Also Exif uses an Application Marker for inserting data, but Exif uses APP1(0xFFE1) Marker to avoid a conflict with JFIF format.

[saurabheights]

@j256 : will the above comment suffice(comment is updated with xxd and EXIF marker information)?

[j256]

Yeah I've been looking at the raw bytes and I've also looked at both webpages you linked to interesting enough (yay google). Both the II and MM exif file headers should have a 0x8769 (either big or little endian) and I'm just not seeing that. This is something different.

In looking at the linux file command code a bit (https://github.com/file/file/), they now support "recursive" patterns which is news to me. Looks like the jpeg stuff has been rewritten to support this. I'm not going to support that anytime soon. Sorry.