Canon Community Canon Community
 


Reply
Occasional Contributor
Posts: 14
Registered: ‎07-03-2017

Re: DPP4 Adobe RGB processed incorrect

Yes, in the current version (4.8.20.0) I also still set the low output level to 10 (in the Tone Curve Adjustment tab) and copy that to all files in the folder.

That's going to be a hassle when canon fixes this bug...

I am not sure whether to overall look is different from DPP3, not in my experience.

 

For the rest I still love DPP for its true-to-life color reproduction and flexible, fast way of grading a raw file.

I'll never switch to Adobe for raw editing (even though I have the master suite).

 

@

I'm sorry that I never replied to your last post :-(

New Contributor
Posts: 4
Registered: ‎04-04-2018

Re: DPP4 Adobe RGB processed incorrect


@Skieswrote:

Yes, in the current version (4.8.20.0) I also still set the low output level to 10 (in the Tone Curve Adjustment tab) and copy that to all files in the folder.

That's going to be a hassle when canon fixes this bug...

I am not sure whether to overall look is different from DPP3, not in my experience.


It definitely looks different in DPP3. I have some RAWs where there is relevant detail in the shadows that is pretty much lost in DPP4 (unfortunately I cannot publish them for legal reasons).

 

Setting the minimum output threshould to 10 can only be a crude workaround because it means that the output file will not contain any darker tones than that value of 10 at all. This is different from what DPP3 produces. I also tried playing with the tone curve in DPP4 to produce similar output as in DPP3 but without success. It seems that DPP4 pre-applies a higher contrast and that is hard to undo.

 

@Skies: have you reported this problem to Canon so that we can hope for a fix? I also very much like the colors from DPP and not being able to use DPP4 with never cameras kind of puts me off when it comes to buying new Camera bodies from Canon.

Occasional Contributor
Posts: 14
Registered: ‎07-03-2017

Re: DPP4 Adobe RGB processed incorrect

@Tomri:

I believe I did report this but can't remember how.

 

All raw editing from DPP3 is lost in DPP4, maybe that is part of your problem?

If I set the low output level to 10 I get my shadow detail back. (Using Adobe RGB)

Maybe it is not consistent with different camera models?

New Contributor
Posts: 4
Registered: ‎04-04-2018

Re: DPP4 Adobe RGB processed incorrect


@Skieswrote:

@Tomri:

I believe I did report this but can't remember how.

 

All raw editing from DPP3 is lost in DPP4, maybe that is part of your problem?

If I set the low output level to 10 I get my shadow detail back. (Using Adobe RGB)

Maybe it is not consistent with different camera models?


I noticed that most (all?) of the settings stored in a RAW are ignored when moving from DPP3 to DPP4. For the purpose of my test I reset images to "as shot", then made sure ALO was off and then compared the results. So the outcome should not have depended on any previous editing. By the way, it was one of the big strenghts of DPP3 to give me good results by default, so having to individually tune images in DPP4 would be a big downside if it was necessary to bring back shadow detail that was there by default in DPP3.

 

I do believe you get the shadow detail back by dialing in a minimum output level of 10, but then the resulting JPEG file will not contain any real blacks, as I understand. Actually it should then not contain any levels <10. This is not what I want. Some photos have black or near black areas and I do not want them to become "grey".

 

Occasional Contributor
Posts: 14
Registered: ‎07-03-2017

Alternative workaround.

[ Edited ]

So I just though that the problem had been solved in version 4.8.30.0, but I was mistaken.

It exported to sRGB and I had to restart the program to reset to aRGB.

 

However, I have found an alternative workaround, that seems to to a slightly better job on keeping details in near-black areas.

 

Instead of using the curves like mentioned earlier, you can also move the output level line of the Gamma display in the 'Basic adjustment' tab, as shown in the attached screenshot. Unfortunately it is not possible to type a value for this setting. The value on the screenshot seems to give a close comparison to sRGB.

 

By the way, the same applies for those working in Wide Gamut RGB.

(As you can see, DPP scales nicely with 200% scaling on 4k display)

 

gamma.png

Esteemed Contributor
Posts: 4,434
Registered: ‎06-25-2014

Re: Alternative workaround.

I continue to believe what I said in messages 15 and 17. Why am I wrong?

Bob
Boston, Massachusetts USA
Occasional Contributor
Posts: 14
Registered: ‎07-03-2017

Re: Alternative workaround.

I just did a test by setting the "Color matching settings" to Adobe RGB and set my monitor to adobe ARGB, and the photo to ARGB.

 

Then I did the same for sRGB, and the result is still, that sRGB shows a lot more detail in the shadows.

 

And as mentioned before, the exports for sRGB and ARGB have different results when viewing in Photoshop, or any other ARGB supported viewer (as can be seen in my start post).

 

When I convert an ARGB file to sRGB in Photoshop, the photo does not change visually, but the histogram does, as it should.

Thus, it is a bug in DPP.

 

Exports for ARGB and sRGB should look identical, and since DPP4 they don't.

ARGB, as well as Wide Gamut RGB and other profiles from DPP4 have clipped shadows, while sRGB does not.

Esteemed Contributor
Posts: 4,434
Registered: ‎06-25-2014

Re: Alternative workaround.


@Skies wrote:

I just did a test by setting the "Color matching settings" to Adobe RGB and set my monitor to adobe ARGB, and the photo to ARGB.

 

Then I did the same for sRGB, and the result is still, that sRGB shows a lot more detail in the shadows.

 

And as mentioned before, the exports for sRGB and ARGB have different results when viewing in Photoshop, or any other ARGB supported viewer (as can be seen in my start post).

 

When I convert an ARGB file to sRGB in Photoshop, the photo does not change visually, but the histogram does, as it should.

Thus, it is a bug in DPP.

 

Exports for ARGB and sRGB should look identical, and since DPP4 they don't.

ARGB, as well as Wide Gamut RGB and other profiles from DPP4 have clipped shadows, while sRGB does not.


The whole point of having different gamuts is that they shouldn't look identical. If they do, it's because the software is presenting you the image in the gamut it thinks your device prefers. If that were not the case, different histograms could not produce an identical visual result. (Your eyes might not be up to seeing the difference, but that would be a different issue.) The obvious conclusion from your symptoms is that DPP is showing you the image in one gamut while the device on which you're viewing it prefers another. DPP allows you to work in one gamut while producing the converted file in another. If that's what you want but it isn't what you're getting, you have something set wrong.

 

It's important to remember that in almost all cases it's the printer that dictates what gamut should be used to convert the file. If the printer can handle the wider Adobe RGB, it probably makes sense to use it. If it can't, you should stick to a gamut it can handle, which is probably sRGB.

Bob
Boston, Massachusetts USA
Occasional Contributor
Posts: 14
Registered: ‎07-03-2017

Re: Alternative workaround.

You are missing the part where I write that in PHOTOSHOP, ARGB en sRGB look identical. So even if it would look different in DPP, it should still look identical in Photoshop. So DPP export wrongly.

 

 

I do understand that when your system- and screen profile is ARGB the sRGB image would be missing some depth, but when already viewing as sRGb the difference is not visible. Try for yourself....

 

IT IS A BUG introduced in DPP4. I have used DPP 3,2 and probably 1 since 2005. And those versions did not have this problem. Thanks ;-)

New Contributor
Posts: 4
Registered: ‎04-04-2018

Re: Alternative workaround.


@Skies wrote:
(...)

 

IT IS A BUG introduced in DPP4. I have used DPP 3,2 and probably 1 since 2005. And those versions did not have this problem. Thanks ;-)


This is also my conclusion. So where is the place to report bugs to Canon?

powered by Lithium

LIKE US on Facebook FOLLOW US on Twitter WATCH US on YouTube CONNECT WITH US on Linkedin WATCH US on Vimeo FOLLOW US on Instagram SHOP CANON at the Canon Online Store
© Canon U.S.A., Inc.   |    Terms of Use   |    Privacy Statement