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

Started by KolinP (aka ColinIM), September 18, 2014, 12:24:24 AM

Previous topic - Next topic

KolinP (aka ColinIM)

Hello ExifTool Forum folks - and hello Phil,

Please consider adding the .JPE file extension to those extensions which exiftool recognises by default.

(I'm a long time ExifTool user (mostly in a GPS context until recently), and a long time IMatch user, and (incidentally) an occasional programmer, but not in perl!.) (My Request below is sincerely not intended as a plug for IMatch. I simply tell it as I find it ... I hope that's OK.)

The Konica-Minolta 'DiMAGE A2' camera gave a .JPE file extension to images that it took when it was set to shoot in the AdobeRGB colour-space (see my reference 1 below), and because exiftool does not include the .JPE extension among those which it recognises (by default), then IMatch obtains no metadata from these files when it calls exiftool to scan them on its behalf.

(As you will know, but I include it here for completeness) This exiftool parameter will show that the .JPE file extension is absent from exiftool's "supported file extensions":

exiftool -listf

Among my 8,070 Konica-Minolta 'A2' image files I have 2,680 "AdobeRGB" .JPE files which I'm unable (so far) to manage using IMatch version 5.

My system is Windows 7 Pro, 64-bit on an Intel i7 Processor with 16GB RAM.
I'm using ExifTool version 9.70.
I attach a sample image file with a JPE extension, named PICT0363-Fs(Rsz480w).JPE

I 'shrank' this sample image to 480 pixels by 360 pixels using Version 5.1 of FastStone Image Viewer for Windows.  FastStone Viewer discards the ICC profile (and probably some other metadata) from images that it "Saves", but it faithfully propagated the bulk of the original EXIF data from the original file. (The Konica-Minolta A2 camera did not add any IPTC or XMP data to its image files.)

These .JPE files are in fact 100% orthodox "JPEG Format" files just like all normal .JPG files, except that they've got a different file extension.  I can 'prove' this fact simply by renaming a 'JPE' extension to 'JPG', and then (when the renamed file is re-scanned in IMatch) I see that the embedded EXIF data is successfully passed 'upwards' into IMatch.

Also I can use this exiftool command to confirm that these .JPE files do contain a 'full' set of extractable EXIF data:

exiftool -m -ext jpe *.jpe

Because these files are really just JPEG "BaseType" files, I considered attempting myself to change my local copy of the exiftool_config file which IMatch uses, to add .JPE as a new "User-defined file type to recognize", but this was deep water that I preferred to avoid, and anyway it wouldn't have been the most elegant solution.

I had been undecided whether to post this Request (for some way to include .JPE files) on this exiftool forum, or to raise it instead on the Imatch / community Forum - because (as you'll know) IMatch now uses exiftool as the 'metadata mainspring' of its Digital Asset Management / database program, and after all, I first met this problem in an "IMatch 5" context.  But I've decided to come to you first Phil because, even though Mario Westphal might be able to modify the 'args' files he uses when he calls exiftool, or he could maybe adapt his exiftool _config arrangements to include .JPE files, I humbly hope that exiftool itself could be (dare I say) more straightforwardly(?) changed to include this probably-not-very-rare .JPE file extension in a future update?

Finally, I did search these boards for similar Requests to this one, and I found this post - posted on: November 04, 2010, 12:56:34 PM - and it includes a reply from yourself Phil -

Reversed Geotagging not working with jp4 image files
https://exiftool.org/forum/index.php/topic,2919.msg13021.html#msg13021

In your reply in that post, you pointed out that the OP could solve his problem (of exiftool not including the .JP4 extension) by using the -ext option to include (just) .jp4:

exiftool -ext jp4

but I fear that this -ext option alone would not resolve my wish to have .JPE files "accessed" straightforwardly by IMatch.

Related info' - Reference 1:
This Konica-Minolta website FAQ Answer confirms that the DiMAGE A2 camera would create images with a .JPE file extension when the camera was set to take images using the AdobeRGB colour gamut:

http://www.konicaminoltasupport.com/index.php?id=4569&tx_faqmanager_pi1[question]=4093&tx_faqmanager_pi1[product]=58&tx_faqmanager_pi1[producttype]=1&tx_faqmanager_pi1[swords]=jpe&tx_faqmanager_pi1[matchswords]=AND&tx_faqmanager_pi1[category]=25

(Sorry. That FAQ link won't render a a url!  I hope it can be copied+pasted as text.)

That FAQ Answer says: (quote)The images captured with "Embedded Adobe RGB" color mode setting are saved with the extension "*.JPE" with which an ICC color profile is embedded.(/quote)

Related info' - Reference 2: Possibly of interest (and as a gentle extra 'nudge' from me!)
In April 2012, following an emailed request from me, the authors of the Picture Information Extractor utility (PIE) added support for the JPE extension in their PIE version 6.20 update! See the "6.20" entry on this page:

PIE Recent History:
http://www.picmeta.com/download/pie-history.htm

Sorry for such a torturous and long first-post!!  And I hope you will consider making this adjustment to include the .JPE extension.

Thank you,
Colin P.
(My Username on the IMatch community forum is ColinIM)

Attached sample filename:  PICT0363-Fs(Rsz480w).JPE
Someday we won't need to sleep ...

Phil Harvey

Wow, that was lengthy. ;)

ExifTool 9.71 will recognize the JPE extension, and process it the same as a JPEG image.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

KolinP (aka ColinIM)

Whew!  Excellent!
Thank you Phil!

(I'll now update the folks on the IMatch Community/Forum, where I left another too-long note about this earlier today :-) )

Best regards,
Colin P.
Someday we won't need to sleep ...