The initial bug report was http://bugs.kde.org/show_bug.cgi?id=148507. Following the given advice I added a new mime type definition for JPEG 2000 files to freedesktop.org.xml.in (patch is attached).
Created attachment 11087 [details] [review] freedesktop.org.xml.in.diff
2007-08-31 Bastien Nocera <hadess@hadess.net> * freedesktop.org.xml.in: Fix JPEG-2000 mime-types and magic to follow the RFC (Closes: #11942) * tests/list: s,image/jpeg2000,image/jp2
Actually, the provided information in http://webcvs.freedesktop.org/mime/shared-mime-info/freedesktop.org.xml.in?revision=1.274&view=markup <mime-type type="image/jp2"> <_comment>JPEG-2000 image</_comment> <magic priority="50"> <match value="jP" type="string" offset="4" /> <match value="\xFF\x4F\xFF\x51\x00" type="string" offset="0" /> <match type="big32" value="0x0c6a5020" offset="3"/> </magic> <glob pattern="*.jp2"/> <glob pattern="*.jpc"/> <alias type="image/jpeg2000"/> </mime-type> is not entirely correct. <match value="jP" type="string" offset="4" /> <- this is redundant <match value="\xFF\x4F\xFF\x51\x00" type="string" offset="0" /> <- I guess this is for *.jpc which is JPEG 2000 code stream format and different from JPEG 2000 therefore shouldn't be included 'cause it's another format <glob pattern="*.jpc"/> shouldn't be included either The provided patch - <mime-type type="image/jpeg2000"> + <mime-type type="image/jp2"> <_comment>JPEG-2000 image</_comment> + <magic priority="50"> + <match type="big32" value="0x0c6a5020" offset="3"/> + <match type="string" value="jp2" offset="20"/> + </magic> <glob pattern="*.jp2"/> + <glob pattern="*.jpg2"/> + <alias type="image/jpeg2000"/> + <alias type="image/jpeg2000-image"/> + <alias type="image/x-jpeg2000-image"/> </mime-type> follows the JPEG 2000 specification and information which is common on the internet (e.d. aliases) and was gathered after a careful study of the subject. I think the already provided new definition in freedesktop.org.xml.in should be replaced by the one in the patch.
Several users of the shotwell photo management application have found odd files that would not import due to be detected with a mime type of image/jp2. In my case one image of approximately 3,000 from the same camera is detected as image/jp2 with all the others being detected as image/jpeg. Another user has a similar experience with a much larger collection and a slighty higher number of files detected as image/jp2. Suffice to say I do not believe a digital camera would randomly write the odd JPEG 2000 file when it normally used JPEG as its output format and through investigation I have come to the conclusion the problem is caused when the length of the EXIF section of a regular JPEG file happens to match one of the rules for detecting a JPEG 2000 file freedesktop.org.xml There is more detail including links to sample files in the shotwell issue: http://redmine.yorba.org/issues/5693
(In reply to comment #3) > Actually, the provided information in > http://webcvs.freedesktop.org/mime/shared-mime-info/freedesktop.org.xml. > in?revision=1.274&view=markup > > <mime-type type="image/jp2"> > <_comment>JPEG-2000 image</_comment> > <magic priority="50"> > <match value="jP" type="string" offset="4" /> > <match value="\xFF\x4F\xFF\x51\x00" type="string" offset="0" /> > <match type="big32" value="0x0c6a5020" offset="3"/> > </magic> > <glob pattern="*.jp2"/> > <glob pattern="*.jpc"/> > <alias type="image/jpeg2000"/> > </mime-type> > > is not entirely correct. > > <match value="jP" type="string" offset="4" /> <- this is redundant Not only is the match rule immediately above redundant is also suffers from false positives which are the reason I have re-opened this bug. Here is a hexdump of the start of a regular JPEG file: 00000000 ff d8 ff e1 6a 50 45 78 69 66 00 00 49 49 2a 00 |....jPExif..II*.| 00000010 08 00 00 00 0c 00 0f 01 02 00 06 00 00 00 9e 00 |................| 00000020 00 00 10 01 02 00 0f 00 00 00 a4 00 00 00 12 01 |................| 00000030 03 00 01 00 00 00 01 00 00 00 1a 01 05 00 01 00 |................| 00000040 00 00 b4 00 00 00 1b 01 05 00 01 00 00 00 bc 00 |................| By chance the length of the EXIF data is such that the encoded length matches the characters jP and thus causes this file to be detected by the rule above as image/jp2 when it is not. Unfortunately the latest version of freedesktop.org.xml still includes this faulty rule.
commit 9d8849fa72720b458171acbcbcc13696f983d134 Author: Bastien Nocera <hadess@hadess.net> Date: Mon Sep 30 12:03:46 2013 +0200 Correct JPEG2000 definition *.jpc and *.j2k relate to JPEG 2000 codestreams, not to JPEG 2000 images, so remove those globs. Remove the jP magic, as it creates false positives (and add a test for that). Also add the jp2 string magic. With help from Steve Fosdick <other@fosdick.me.uk> https://bugs.freedesktop.org/show_bug.cgi?id=11942
Use of freedesktop.org services, including Bugzilla, is subject to our Code of Conduct. How we collect and use information is described in our Privacy Policy.