Why does PL create a dop file for a jpg after I export to jpg? What is that used for?
PL is a non-destructive editor. The DOP contains the edits to the original JPEG and, when you export, the resulting JPEG is a combination of the original and those changes, leaving the original untouched.
1 Like
I should have been more specific. I edited a raw file, exported a jpg, and then found a dop file associated w/ the raw file and a dop file associated w/ the jpg file (2 dop files). What is the purpose/use of the jpg dop?
If you exported the JPEG to the original folder and the opened it in PL, thatâs when the DOP would have been created.
If you have not the default preset for no-RAW images to âno correctionâ and you have selected a JPEG then PL will apply the default preset and write that âeditâ to a .dop file.
nothing 
As an experiment: close PL, create a new folder and copy this JPEG and its DOP file, as well as a renamed version of the same JPEG, there.
Open this new folder in PL and compare both JPEGs â no difference, they are identical.
.
Well, there is a purpose âŚ
â If you donât preset your RGB images to âNo Correctionâ, but âŚ
your unaccompanied & newly discovered JPEG can look different â see ⌠.
The sidecar/.dop file associated with the RAW file contains (the final state of) all the correction information applied to it ⌠as used to generate your JPG.
Then, when PL opens the resulting JPG it applies the preset defined in PLâs preference settings - with all associated correction settings written to an associated sidecar/.dop file.
- However, in the case where the JPG was generated by PL (from corrections applied to the RAW file), PL is smart enough to know that it should not reapply all the previously applied corrections - so, it makes no changes at all (as explained in Wolfgangâs post, above).
Note:
-
It sounds like you may be exporting your JPGâs into the same folder where your source/RAW files are located ⌠which results in the confusion you are experiencing - with RAW files, their associated sidecar files, plus exported JPGs and their associated (âdo-nothingâ) sidecar files are all mixed up together.
-
You can make this simpler by exporting to a different folder ⌠See the export âPathâ option.
@PixPixPix I cannot create your scenario after tests with both PL5.16 and PL7.8, I went back to an earlier DxPL release because I believed that DOPs were automatically created in more scenarios than my test showed.
My tests showed the following
- With a directory containing a RAW and JPG image discovery in DxPL did not result in a DOP in both cases regardless of the default presets used i.e. I started with
in PL5.16 (and the equivalent in PL7.8) and ended with
in both releases, i.e. not just in the case of a âNo correctionâ default.
Discovering those two images never resulted in the creation of a DOP unless I made an actual new edit or exported the image, to any directory (albeit I was specifically exporting to the same directory)!
-
Exporting the RAW and JPG to a JPG in the same directory resulted in the new images being discovered by DxPL and entries being created in the database but no DOPs were created for those exported images.
-
Regardless of the âPreference settingsâ the new exports were assigned the appropriate âNo correctionâ default preset for the release, i.e.
@PixPixPix I am glad you created the post but I cannot understand where the DOP for the exported JPG came from!?
⌠already explained above
@PixPixPix revised his original statement to the one above and responses identified that the export must have been done to the same directory and therefore DxPL detected its presence and created a DOP
, except that according to my test results it doesnât, it allocates a âNo Correctionâ edit to the exported image and doesnât create a DOP!!
My tests follow @PixPixPix steps exactly except that I have a RAW and a JPG image to start with.
Regardless of the settings I put in âPreferencesâ discovering those original images with an empty database will not result in a DOP until an edit or an export is made by the user.
I included that bit of description because I consider it a risky decision by DxO to only have the edited image in the database at that point.
I then exported to the same directory and got the two images immediately discovered by DxPL as expected.
These were added to the database (along with an entry for each identifying an export!?) but with no DOP created which is contrary to what @PixPixPix and others in this post have stated hence my issue over a missing DOP, i.e. missing from my test results, as I expected because I have encountered this before.
My snapshots showed that I opened each but I had no DOP created when I just opened an image.
From the original query my issue is with the absence of a DOP in my case, regardless of what is in the âPreferencesâ .
My second issue is that not creating a DOP when first discovering an image avoids the complaints about DxPL creating DOPs all over the place but the risk is that losing the database (accidentally or deliberately) means that whatever was applied in that initial discovery will be lost.
My third issue is that applying a âNo Correctionâ preset to the newly discovered JPG puts those JPGs out of line with other JPGs in the directory, whether that is right or wrong is open to discussion.
PS:- Opening the exported images in âCustomizeâ did not result in a DOP being created. i.e. I made no edit moved to the second export and then back to the RAW and closed PL7.9 (as it is now) and got this in the directory but did not get any DOPs for the exported images.
Thanks again gang. Iâll just add something to the bat file I use to start PL which will sweep my dir structure where I keep image files to delete anything that contains jpg.dop in its name.
Clumsy, clumsy. Before opening PL my bat file deletes the database, after PL exits it deletes the useless jpg dops.
Still beats LR
Noting, again âŚ
@John-M While I agree with your statement about exporting to another directory I reran my tests!
@PixPixPix I was a little disappointed that you made no response to my post so I ran the test again using a program called (NodeSoft)FolderMonitor and this was set to âwatchâ the one directory of the original test images and where the exported images were created and we have
PL7.8 Preparing for Export:-
PL7.8 After Export:-
FolderMonitor Log for the âwatchedâ directory:-
At no point is a DOP created for either of the two exports added into the âwatchedâ directory which is almost certainly using the same process that DxPL is using to monitor the activity of the directory that is currently open in DxPL.
The Test directory after PL7.8 Closedown:-
