Hello,
I work my Nikon raw files with Lightroom.
The meta (exif) data that Lightroom exports to tif or jpg files is somehow different from the raw file.
With another SW I always had problems with exactly these changed meta-data.
So since then I copy the meta data of the raw files to the exported tif/jpg files.
This works very well with the command exiftool(-tagsfromfile %d%f.NEF -ext jpg -overwrite_original).exe
In the meantime I have noticed the following:
- Before copying the Exif data, the JPGs exported from Lightroom are correctly displayed as "large icons" in the Win10 explorer
- After the copying process with exiftool, the symbols in the Explorer are often displayed incorrectly.
I do not know whether the preview images themselves are changed with the copy command or whether only the display in the Explorer is faulty due to the changed Exif data.
Does anyone have an idea what the problem could be and how it could be solved?
Thanks for your support!
When you say "displayed incorrectly", what exactly is the problem? For example, do they show up all black, or just with the wrong colour profile, or just the wrong size?
Could you post a (hopefully small) problem JPG so we can take a look?
- Phil
Hello, Phil,
mostly the lower half of the thumbnails in the explorer view "large icons" is displayed in grey. The upper half seems to be correct.
Image 780_3183 was created with Lightroom and is displayed completely correctly (here ...-copy.jpg). The preview image of the corresponding NEF file is also displayed completely correctly.
After the command exiftool(-tagsfromfile %d%f.NEF -ext jpg -overwrite_original -k).exe has been applied, the lower half of the preview image of 780_3183.jpg is displayed grey in explorer preview "large icons".
The original file gives a File contains multi-segment EXIF warning. My guess is that the thumbnail is split between two segments and Windows is not able to process a multi-segment EXIF.
Not my area of expertise, so someone else will have to double check the file to see if that's the problem.
I found this old post regarding a case where Mac Finder couldn't display the thumbnail properly.
Quote from: Phil Harvey on September 17, 2018, 08:06:09 AMMulti-segment EXIF is not well supported by other applications (only Adobe products and ExifTool support this as far as I know). So if you get this message you may very well find that EXIF metadata (ie. the thumbnail image) is not extracted properly by other apps. To fix this, reduced the size of the thumbnail or other metadata to get the EXIF below 64 kB.
I think StarGeek nailed this one.
The main space hog is the ShotInfo from the NEF maker notes, which is 51 kB. I'll analyze a D780 NEF and JPG when I get a chance to see what Nikon does about this.
- Phil
Hello,
I made another observation, but I'm not sure if this helps: if I rename the jpg that is not displayed correctly as "large icon" to png, it will be displayed correctly. If I change the extension back again, unfortunately it's like in the beginning :(
- Peter
Hello Phil,
would it help if I could somehow make the corresponding Nef-File available, e.g. via drop box?
For the normal upload tool it is too big (27 MB).
- Peter.
Quote from: pemiwi on June 11, 2020, 02:34:38 AM
I made another observation, but I'm not sure if this helps: if I rename the jpg that is not displayed correctly as "large icon" to png, it will be displayed correctly. If I change the extension back again, unfortunately it's like in the beginning
I'm pretty certain now that the problem is that the thumbnail is split. Renaming it to a PNG, which Windows has extremely poor support for so it probably can't read a thumbnail in a PNG, forces Windows to read the whole image in order to make the icon image.
If I remove the thumbnail with
exiftool -ThumbnailImage= file.jpgthen the same thing happens. There's no thumbnail in the EXIF for Windows to read and it displays the file properly.
There is a
PhotoshopThumbnail in the file but I really doubt that Windows will read that.
In the meantime, I created a dropbox link to the corresponding Nikon Raw-File:
https://www.dropbox.com/s/7t7c9oc1ujm24o1/780_3183.NEF?dl=0 (https://www.dropbox.com/s/7t7c9oc1ujm24o1/780_3183.NEF?dl=0)
I've looked at a D780 JPEG file and the ShotInfo is only about 23 kB. Since I don't know how to reduce this from the 51 kB found in the NEF, I can't save space this way. But the ContrastCurve isn't found in the D780 JPEG, so I will avoid copying this, saving 578 bytes, which will be enough to just avoid this problem with the file you posted. Look for this update in ExifTool 12.00
- Phil
Hello Phil,
I just did some tests with the new version of the ExifTool. It seems to work perfectly!!
Thanks a lot for the great support, also to StarGeek.
I was just on the donation page :-)
- Peter
Great, thanks!
BTW, I also added a NoMultiExif API option (http://exiftool.org/ExifTool.html#NoMultiExif) to allow you to avoid writing multi-segment EXIF if you want. Just add -api nomultiexif to your command. With this option you will get an error if the EXIF doesn't fit in a single JPEG segment.
- Phil
Hello Phil,
In the meantime I have copied the exif data of NEF files for some more Jpgs. Unfortunately, there are again some files which do not work even with version 12.00. Their thumbnails are still not displayed correctly.
I have now simply removed the thumbnails completely, as suggested by StarGeek. This is also okay for me.
Quote from: pemiwi on June 13, 2020, 06:17:20 AMI have now simply removed the thumbnails completely, as suggested by StarGeek. This is also okay for me.
Well, I didn't really suggest it, it was just part of my testing :)
But on a modern computer, it really shouldn't be a problem. Unless the image dimensions are huge, the desktop thumbnail should be created as fast as the file is read and then the
thumbs.db file should cache the image after that.