John – that’s possible.
Personally, I don’t want any JPEGs and TIFFs to be altered,
as for me they are “output files.”
John – that’s possible.
Personally, I don’t want any JPEGs and TIFFs to be altered,
as for me they are “output files.”
The same for me.
George
When applying the preset optical correction only to a jpg nothing happens. But when applying B/W it changes to B/W. So it seems some presets don’t work with jpg.
George
Yeah, apologies - - I confused matters by making reference to a file “exported from a processed RAW”.
Forget that - - - Consider this instead;
1) I export two TIFFs to Affinity and stitch a panorama - and then I export the resulting image (say as a JPG) from Affinity without embedded EXIF data
2) I export exactly the same pano image from Affinity with embedded EXIF data
What’s the reason for the different handling ??
Care to post those images or have a look at them with ExifTool?
Sure - Here are 2 JPGs created as outlined in post just above … labelled with/without EXIF data.
AffinityPano_JPGs.zip (7.9 MB)
Is it perhaps the case that PL finds a reference to itself in the “Software” entry in EXIF data - and therefore determines it shouldn’t go another round ? … Whereas, with no EXIF data it behaves differently ?
a side note - with linear DNG for DxO PL it is a matter of some tags ( it was about round trip with linear DNG when DxO PL6 was not applying a preset that was set to be applied by default to its own output )
quoting from my old post from May 15 =
"so just running a script with
exiftool -CreatorTool= -Software= %1 -overwrite_original
before invoking DxO PL executable makes the linear DNG perfectly new ( to PL ) and preset applies as it shall be
PS1: removing either tag works, but I remove both just in case"
may be just gutting some tags in TIFF or JPG will work ?
In thinking thru this for myself (thanks for the prompt, Mr P) - that explains the behaviour, and it makes logical sense … 'cos PL is attempting to avoid the potential for applying corrections twice.
In my case, tho, I DO want my custom RGBpreset to be applied - and NOT the “No Corrections” preset … but I cannot think of a way to force that (without manual intervention).
I first emptied the SoftwareVersion tag. No difference. Then I emptied the CreatorTool tag and the image did get the preset from the preferences.
George
You need empty them both. I don’t know if this is of help.
George
Had a go with your files and found that DPL6 on macOS does as you wrote.
I then copied the file that has the extra tags and edited some out with a hex editor.
Although I deleted the database between each test, the behavior I found feels very odd.
Yes, it does, and I found that EXIF also says Color Space = “Uncalibrated”.
For the time being, there’s still the possibility to apply presets manually until the puzzle is solved.
This came to mind.
Thanks for the confirmation …
I’m guessing that’s PL’s method of dealing with the case where a user exports (from PL) into the same folder as the source-image/RAW file … in order to avoid re-applying corrections.
Unfortunately, I can’t think of any better way for PL to handle this (??)
It simply sets Soft Proofing ON, with ICC Profile = sRGB … Nothing else.
This is necessary (for my personal workflow), because;
I export images to Affinity for pano-stitching with ColorSpace = PhotoPro RGB … to give Affinity as much detail as possible to work with … and then export back to PL with same ColorSpace.
I then open the panorama image with PL (for minor tidy-ups such as straightening, cropping, etc) - and I expect it to apply my RGB auto-preset … so that Soft Proofing is set ON, with ICC Profile = sRGB
When I apply my standard Export to Disk settings, the ICC Profile used will be “Same as Soft Proofing” … which will export with ICC Profile = sRGB …
However, if Soft Proofing is NOT activated then “Same as Soft Proofing” defaults to the ColorSpace of the source-image … which, is PhotoPro RGB !!
– Which looks rather “flat and lifeless” on a less-than-capable monitor
… To which my only response is “On this Churly Morn” … Same bard - same slim volume.
Note: I have updated the heading on this post;
From: A PLv6 bug ? … Applying a default preset to “new” images”
To: Behaviour to be aware of - when default preset is applied to “new” images”
And I’m not holding my breath while waiting for any different behaviour … So, I’ve changed my Export preset from Affinity so that it no longer includes any EXIF data in the file exported back to PL … So, PL now does auto-apply my RGB preset (instead of its “6 - No Corrections” preset).
As far as I can see PL doesn’t apply automatic a preset to a jpg/tif that was created with PL. You’ve to apply it manual.
George
@John-M thanks,
Note tomyself, check which preset i have for none rawfiles?
I never bothered to look (i think i did once by installation) at this because i assumed that “no correction” would be the case.
1 OOC jpeg are cooked already as a blistermeal from supermarket so dxopl is then my kitchen to get it eatable, some herbs and spices apply some heat done.
2 tiffs are often exported out dxo from a rawfile and stage two editted elsewhere before they return in the filmstrip of dxo for end export to jpeg. So no correction needed.
3 mobilephone photo’s? Well that are often overcooked meals so manual control to avoid more damage is prefferable.
4 scans of photo’s? Same please let me decide.
So a consistence no correction in automated form would be fine.
By giving the choice to the user. More options in preferences, or either in a request window.
With the result of having no exif in your mage. Isn’t that a bigger problem than adjusting the images in PL manual, either individual or by group?
George
That doesn’t bother me, George … as I still have the EXIF info in the images used for the panorama.