The awkward file extension .JPE from Konica-Minolta cameras

[ColinIM]

I've posted a Request on the ExifTool forum to ask for the file extension .JPE to be included among the file extensions which exiftool recognises by default:

Please include files with extension .JPE as from Konica-Minolta cameras

The currently 'recognised' file extensions which exiftool identifies and from which it can feed back metadata when called by IMatch, are seen by running exiftool in the ECP with this single parameter:

    -listf

That parameter tells exiftool to "list all supported file extensions" ... and .JPE is absent.
(Note: the exiftool -list parameters don't require any image to be specified, and the -list parameters on their own do not modify any data at all.)

That post on the ExifTool forum is (once again from me) lamentably long and verbose, but hopefully Phil Harvey will be swayed by my argument.  If he isn't persuaded to add yet another variation to the already numerous .JP[something] extensions for JPEG Format files, then I'll be back here to add a Feature Request, hoping that Mario can devise some solution to my problem.

Here's a summary of it:

IMatch 5 is unable to extract any metadata from 2,680 of my 8,070 Konica-Minolta 'DiMAGE A2' ('A2') image files because:

(a) the 2005-era 'A2' camera gave a .JPE file extension to images that it took when it was set to shoot in the AdobeRGB colour-space, and
(b) to my surprise, ExifTool does not include the .JPE extension among those which it recognises by default.

The consequence is that - although IMatch 5 is able in all other respects (as far as I can tell) to give full EXIF and other 'variable' related support to files with a .JPE file extension, IMatch obtains no metadata at all from exiftool for these files - so the metadata panel for these files (and only these .JPE files) remains blank.

If perhaps Phil Harvey can't or won't incorporate my request, and then if afterwards Mario too is unable somehow to 'include' .JPE files then I might return to my local copy of the exiftool_config file which I presume IMatch invokes each time it calls an exiftool instance. (My presumption is based on a search of earlier threads here relating to exiftool_config. I haven't confirmed this for myself yet.)

Inside these exiftool_config files there's a tantalising section labelled as "User-defined file types to recognize", and (given that the .JPE files are part of the already recognised "JPEG BaseType", it might be feasible to welcome these .JPE files into my IMatch 5 database after all!

If I've missed any other possible option(s) for .JPE files then I'm all ears 

(Note that, as I say above, the .JPE file extension is not "missing" or omitted in any respect inside IMatch.  Everthing that is .JPE related in IMatch 5 is present and correct just like its .JPG cousin (such as File Format settings and results from Data Driven Categories etc.).  It's only ExifTool which has this blind-spot, as far as I can tell.)

Colin P.

[Mario]

IMatch includes JPE as a standard format. But it will not process files via ExifTool if ExifTool does not list them as supported formats.
Is there a reason why you cannot rename the files to use the .JPG extension?

[ColinIM]

(....) Is there a reason why you cannot rename the files to use the .JPG extension?

Hello Mario,

(Edit: This is now happily a moot point because Phil Harvey has agreed to insert .JPE extensions into exiftool  :
In his reply to my post on his Forum he says:

Wow, that was lengthy.
ExifTool 9.71 will recognize the JPE extension, and process it the same as a JPEG image.
- Phil

But in my (now unnecessary) reply to you Mario, I gave the following reasons for hoping to avoid a rename option except as a last, last resort ...

Yes, renaming the files could (have been) be my last, last resort.

In order not to 'lose' the implicit information in those distinct file extensions, I could append the previous extension onto the new filename, something like this:

PICT3408.JPE   could become  PICT3408_JPE.JPG

But then (and you're welcome to skip the following blurb while I think aloud!) - given that when this fine little 'A2' camera created these AdobeRGB images, each .JPE file was the 'partner' file to to the same-base-named .MRW RAW file (I'm avoiding the term 'buddy file' for the moment), and in addition, each of those .MRW + .JPE file pairs was accompanied by a matching .THM file, so I would want to rename all three files in each image-set:

PICT3408.JPE   could become  PICT3408_JPE.JPG
PICT3408.MRW   could become  PICT3408_JPE.MRW
PICT3408.THM   could become  PICT3408_JPE.THM

(The .THM file is consulted during RAW development by the Konica-Minolta DiMAGE "Viewer" RAW processing program, which I still run on an XP Virtual Machine.)

But, on those now ambiguously-renamed image files, you can imagine that when I or a member of my family re-approached them in say 5 years time, there'd be some head-scratching and likely some doubts about what exactly was meant by a file named "PICT3408_JPE.MRW".  (Although of course I could leave explanatory notes alongside these image folders.)

However, my actual main reason for hoping to avoid a renaming session is that all of my image files, including these A2 files, are archived and stored in multiple backups in multiple locations in for example, assorted, (now)read-only, whole-disk-partition backups, and once these particular 'local' copies were renamed, I'd have a near-perpetual disjoint between these and their previously archived versions.

(I'm certain there's a shorter way of saying all of that    sorry!)

But ... End of another (now hypothetical) muse ...

I look forward to ExifTool version 9.71 in due course, and the cure for this ... ummm ... temporary DAM blind-spot  

Colin P.

[jch2103]

Nice solution by Phil. I took most of my A2 shots using .jpg, because I could process them (but not .mrw files) with DxO.

[cytochrome]

Ah... some real connoisseurs here!! I have over 11000 MRW from an A1. I loved it, was stolen in 2004 in cathedral Saint Trophyme in Arles, I am still in the mourning.

I converted the MRW with Bibble, ASP supports them too. It is a shame DxO does not handle them, could benefit from good denoising. I ditched the THM, they contain a 160x120 jpg and little else. I was too snobbish to shoot jpg, so no JPE problem, just checked on my HDs not a single one!!

Francis