Generating full res JPG and xmp

Post Reply
Posts: 194
Joined: 18 Feb 18 22:21

Generating full res JPG and xmp

Post by Username » 13 Mar 18 23:52

With the new 1121pg I began with a new Postgres db and did some new imports.
I noticed that the Postgres did not grow as before and found out that all metadata is written as xmp-sidecars and a full res jpeg have been created parallel to my NEFs as well.

I did run Build missing thumbnails and previews and the Catalog setting for preview size set to default: 1920.
Why was the full res jpegs created?

What I would like to have is the metadata/xmp stored in my Postgres together with the thumbnails.
I would like my NEFs to stay as they are.
When I do work on my files in DxO, CO etc I'm more then happy to let their sidecars be saved along the NEFs as they should so that PS can create the proper previews and thumbs.

How should I set up the settings in PS to do this?
Auto sync/AUto write out catalog changes to image file: <Unchecked>
Only update out-of-sync images: <Checked>
Store metadata to database only: <Checked>
Allow embedded meta writing for RAW: <Unchecked>

Should I delete all the "created" sidecar files and strange large jpegs and begin importing everything ones again or do you have some smarter solution? :)
- I'm the user

Posts: 21404
Joined: 13 Sep 03 7:24

Re: Generating full res JPG and xmp

Post by Hert » 14 Mar 18 0:02

You can switch off XMP writing. But if you're going to follow industrial standards then you should keep the XMP file just where they are. It is what makes your metadata interoperable if you ever decide to switch to another tool in the future. Any serious metadata tools will look for the XMP sidecar file.
This unlike the proprietary DxO or C1 sidecar files. Those files are only used by those products and are not interchangeable.

PSU will never write JPGs files for your NEF files. Thumbnails and previews are stored in the database. These full res JPGs that you see are not written by PSU. Maybe your RAW converter did?

With the settings that you list you did configure PSU to not write XMP sidecar files (also see my first remark as I think it's a bad idea to not do that). If you don't want XMP sidecar files then you can indeed delete them from disk. Luckily, with PSU you can always write them again if needed.
This is a User-to-User forum which means that users post questions here for other users.
Feature requests, change suggestions, or bugs can be logged in the ticketing system

Posts: 194
Joined: 18 Feb 18 22:21

Re: Generating full res JPG and xmp

Post by Username » 14 Mar 18 0:22

OK thank you Hert. I'll make sure to save the xmp-sidecars.

The full res jpeg have the same MAC-times as the PSU xmp-file and the exit data says:
Programvara: Photo Supreme Server Edition Version
Originalprogram: Photo Supreme Server Edition

So have done something that cause PSU to generate those it looks like. :)
I got to say that I was way to tired to remember what I did.
- I'm the user

Preston B
Posts: 400
Joined: 24 Feb 10 19:01
Location: Columbia, CA

Re: Generating full res JPG and xmp

Post by Preston B » 14 Mar 18 5:42

I have never seen PSu create jpg's from my NEF files. I wonder if you accidentally set your camera to shoot both NEF + JPG? You might want to look at your camera's settings and check.
Preston Birdwell
Columbia, CA

Photo Supreme on Puget Systems Obsidian: Win 10-64 bit Intel i5Quad Core 3.3Ghz 32GB RAM, and Puget Systems Traverse Laptop. Chamonix 4x5 and Nikon D-7100.

Please visit my web site at

Posts: 194
Joined: 18 Feb 18 22:21

Re: Generating full res JPG and xmp

Post by Username » 14 Mar 18 11:35

My cameras are always set to shoot NEF+jpgs, but they are always separated.
I save the NEF to one card and jpegs to another card in camera.
The NEFs are usually stored on server in a separate hierarchy. In this case I probably have made a misstake and placed the jpegs together with the NEFs.

After some testing it seems that if Versioning is activated PSU or select files and ask PSU to do versions. It rewrites the original jpegs and add IPTC data et al. to the file. Thats why I noticed the change and that the MAC-times corresponded perfectly with the XMP-files as well.
- I'm the user

Post Reply