Changing the camera name from Zf to Z6 changes the demosaicing proces. Camera profile is fine tuning it afterwards. My thoughts.
The situation is we have a Zf file with blown highlights that doesn’t appear in other converters. But there is also a Zf file taken a few seconds later under similar conditions with no clipping highlights.
And changing the camera name form the file with the clipping highlights to Z6 doesn’t show these clipping highlights.
It seems that PL has some trouble with the Zf module.
Could you explain the method and tools needed to modify and use your synthetic raw (or maybe provide an other one which covers the whole range of data) in order to adapt it to any camera (if it is only a metadata change to do), so that anyone, whatever their level of understanding of the underlying engineering, can test dxo’s behavior for their camera(s) ?
Maybe creating a new topic with this “recipe” in first message with the aim of collect results would be interesting (DEBUG RAW HIGHLIGHT CLIPPING)?
This would require to ask everyone to post only test results if there is clipping (resulting dng and reading) and not to post anything else nor start any discussion to keep the topic clear. And maybe a link to this topic (or a dedicated one) for any question or discussion would help to keep main topic clear.
This would allow to take stock of the extent of this bug in photolab and report it to DxO as a group.
I know the problem is not everyone has rawdigger, but …
The selective tone sliders are unusable and can degrade the image to some extent making it much duller. I get around the problem with control points, but it takes longer…
Also a recurring problem that I encountered with various cameras (my G9, a Canon 60D and a Nikon D90): if you lower the luminance of the blue in the sky and slightly increase the saturation (using the color wheel) , the sky becomes very noisy. To get around this problem, I use DeepPrime to get a clean image, which is still a shame on an image at 200 ISO.
I still have a very old version of Lightroom (5.7.1), and on the points mentioned above, it remains much better despite the fact that it is old software. It is obviously outdated for the other tools, but at least it reacts exactly as we would expect.
I almost never use selective tone. The overlap is just too great and you need to use the mid-tone in the other direction to reduce that wide range - and you can also get stepping in smooth graduated tones.
You do need to realise that DeepPRIME is not just for high ISO situations - it can, and should, be used for every image, especially if you are getting shadow noise. It is part of me default preset.
take it literally → for the purpose of this thread the donor raw(s) was/were the raw(s) that OP shared for example , we modify the image area data ( sensels’ DNs ) to test what we need to test
Many users believe that DeepPrime is only about noise reduction, this is a mistaken believe. Deep Prime uses also a new demosaicing platform in addition. Therefore it makes sense to use it as default.
what was your request then ? you want to test something for a specific camera model, etc - you take the donor raw that suits the needed conditions like a nominal ISO, etc and proceed as indicated above … do you want to test something for a different camera model or shooting conditions ? you make another donor raw and so on … no, I do not have a magic app where anybody can drag and drop files, I do it manually in Matlab - my last “IT” job was in 1998, so I do not write a code for a living for a long while
and it has simple bugs producing maze artefacts ( the NR tool for DP/DPXD does not offer users any options to control demazing, unlike prev. demosaicks ) for certain camera models where DxO fails to control it internally - apparently “bespoke” camera testing ALSO does not include testing for green channels disbalance in various conditions … if you do not test to control / eliminate maze behind the scenes then make available an option in tool’s UI for a user to control it in DP/DPXD variants
What’s in a name? I did not read John-M’s post as indicating that he believed that the specific problem is with the post-demosaicing application of a faulty camera profile. Just that there is a problem. My take is that a change in the camera name in metadata is apparently enough to trigger a change in the demosaicing algorithm itself.
Still looking. What’s in a name? So you don’t think that a null or faulty camera name / module is enough to trigger a change in the specific demosaicing algorithim?
did you manage to read what camera profile is ? do you need any assistance in finding the explanation in the posting that is just below the posting in question ?
also did you manage to read the original comment way above in this thread
