Crazy Preset File Insight

Just for fun, and seeing @platypus screenshot, I copied a .dop file and renamed it to .txt. Then I was able to open it in Numbers (substitute spreadsheet app of choice). If you are analysing .dop contents, to my mind, it makes it even clearer than opening it in a straightforward text editor because it separates the sections into columns according to their level.

1 Like

Yes, levels can be separated like this. Isolating tools is a different story though. Some of the tools’ settings are spread over several non-contiguous lines… Moreover, the flat view helps to find differences easier without programming…

1 Like

You’re welcome. Please also look into the general presets that come with the app. Some of them contain semicolons instead of commas and such. It does not seem to matter though, I’ve played around with these files too and the syntax requirements seem to be fairly relaxed :wink:

1 Like

@StevenL how does it feel to have two new, unpaid interns on the development staff? :wink:

1 Like

Let me answer for Steven: It feels good, because it 1) improves the quality of the product and 2) it creates some work for the staff, they’d be bored otherwise :wink:

4 Likes

I found one strange thing in one of the presets: The DxO optical corrections only preset lists “unsharp mask” as active, it does not display it in the GUI though.

As we can see (left bubble), the DxO optical corrections only preset was applied.
This preset (re)sets all tools to whatever values and whether they should be active or not.

Looking into the preset that is in the app (middle bubble), I see “UnsharpMaskActive = true”, which imo means that the tool should be acting on the image, which it doesn’t. I can switch USM on and off and see a sharper image when USM is on. So, while the preset says true, the tool is off (right bubble).

Could it be that it is somewhere linked to “is a module available yes/no” if “no” then it is active.

Exactly, the UnsharpMask is active or not depending on whether a module is used or not. SO it may be that.

Am I correct in guessing that USM will go live when NO MODULE is available?

Talking about orthographic inconsistencies, it would be nice if DXO worked towards a visual orthography standard. When I tried out the Nik Collection I was thrown and frustrated by inconsistencies - struggling to work out what some nomenclature meant, sliders and masks working in different ways, and frustrated by having stuff in different places to what my muscle memory had it it from PhotoLab. Maybe an orthographic chief is needed.

Thanks this is a lot of work and I for one appreciate it. I’m not quite sure what I am looking at in your .ods file but following along your narrative I may be able to catch up.

I’ve been curious about DxO presets for a couple of reasons – especially, for example, how are some of the desired elements of the Elite Pack monochrome presets achieved? I would like to apply those changes without using the entire preset, which may change something else. I thought all of the monochrome presets used a saturation level of zero but that doesn’t seem to be the case.

I’ve also created some single-function presets that do only one thing - Prime Noise reduction, for example, or warm filter (=50), or 16x9 crop. These presets are then mapped to a specific function key combo, so that I can go “Cmd-Option-W” to get a warm filter effect, or “Cmd-Option-N” for Noise filter. It’s not possible to do without deep analysis of the presets, but it has made my workflow (and stress on my hands) much easier.

The .ods file is an open document spreadsheet file that contains the settings of most of the tools changed one by one, one in each column in the form of presets. NoCo corresponds to No Correction and you might be able to figure it all out based on the title line and the settings in the lines below that.

Presets contained within DPL, personal presets as documented in the file and .dop sidecar files are built from the same ingredients and wrapped differently. Some items are easy to understand e.g. something like ModuleActive = true, others are not. Some of DPL’s magic is not just a bunch of parameters though, film emulations probably use LUTs too.

do we need to know these details? Certainly not for day-to-day use, but a glimpse behind the curtain can provide new insight…

Yes, that’s it. When it’s not a RAW image, it will be disabled, and on RAW images, it will be disabled in favor of Lens Softness if a module is used.

…which means that, in order to get a true “No Correction” result, we need to activate the USM tool and set sharpening to zero… Odd, but good to know. Thank you.

One more question: What is DNG in this context? RAW or NOT raw?

I’m not following you on this point, Platypus; If USM is not activated then wouldn’t it already equate to the affect of zero sharpening ?

John

@John-M, USM is active on shots that were taken with a combo that has no module. Instead of lens sharpening, USM will be used instead.

Actually, the DNG format is just a container. So inside it, there can be either RGB image data or RAW image data. Typically, some bodies use a DNG container for their RAW images, so it really depends on your DNG images.

I understand this. Still, the differentiation between raw and rgb is unclear because both methods present data about r, g and b light gathered. It would probably be better to talk about mosaiced / demosaiced content.

I understand that a few tools (like DeepPrime) depend on the demosaicing step, nevertheless, all other tools could be used on demosaiced image data too if it were decided so.

Depending on the sensor it might not be true even to use the mosaic as the determining factor.

I guess the original meaning behind RAW is that the data is raw sensor data, with no interpretation done (though possibly with some processing done). If the camera sensor is a Bayer matrix and the file you get from it is not representing that matrix then it’s not RAW. If there was such a thing as a purely monochrome sensor (perhaps in medical imaging?) then each sensor site would truly be one pixel and the “pixel level” data would still be RAW. Whereas “pixel level” data from a Bayer sensor has to have been demosaiced.

So I think RAW means, “what the sensor recorded” and “RGB” means 3-colour pixel data. It is technically possible that a file could be both (with layered as opposed to matrix sensors). Which is why I don’t agree with the use of “RGB” to (typically) describe demosaiced data.

So for most modern intents, and certainly in the “photographer” market, “demosaiced” is the most meaningful term for “not RAW”.

But then you get Apple, who have branded their use of the new DNG 1.6 specification as “Apple ProRAW” where, in fact, the data in the file is demosaiced. :roll_eyes:

Sheesh! It’s just like the old dpi vs ppi discussion all over again :roll_eyes: