PL8.1.0 Still adds Chromatic Aberration to images between 25% and 74% & to the Loupe

I have complained about DxPL adding CA to my images between 25% and 75% in the past, i.e. no CA is or is obvious below 24% and vanishes at 75% and above but is present all the rest of the time?

But the Loupe also manages to add more CA to its image than the image view does above 75%??

I have raised the first issue with DxO Support for PL7 and both issues with DxO Test Support for PL8.

I consider it wholly unacceptable that a Photo editing package “corrupts” the presentation of an image while the user is trying to edit that image. The “excuse” that the proper rendering will only be available above 75% is unacceptable when DxPL is actually adding “corruption” to the image below that magnification.

The screen presentation of the image not being perfect below 75% is one thing, the image being corrupted below 75% is on a wholly different level!

Image @ 23%:-

Image @ 24%:-

Image @ 25%:-

Image @ 70%:-

Image @ 75%:-

Although the Loupe has been showing a less corrupted image up to this point, now the image display is showing less CA that the Loupe!

Image @ 100% versus Loupe @ 100%:-

At 100% for the image and the Loupe, the Loupe is now showing more CA than the rendered image! How does that fit with the notion that the Loupe is supposed to be an accurate rendering of part of the image!?

1 Like

Bryan,

I certainly understand your frustration. Inconsistency is very annoying. In your experience, does the CA make it to the exported images or is it properly corrected?

Mark

1 Like

@mwsilvers You had to ask that question didn’t you. The settings I am using come from an experiment I was conducting some time ago and are potentially not the best for this image.

That doesn’t alter the fact that differences, particularly between 25% - 74% are confusing but this is a snapshot versus the exported image compared in FastStone Image Viewer (FSIV) and scaled and positioned as closely as I can

The snapshot above is not quite as if looking at the images onscreen, currently on my redundant i7 with a 1920 x 1200 monitor attached (sRGB accurate) which shows that the Loupe is potentially a better representation of the final export than the 100% image render.

So we have (way) too much CA 25% - 74% and potentially too little above 75% in the screen render but I would contend that my snapshot shows a “tad” more CA in the Loupe than in the image exported as 100% JPG, or not!?

PS:-

It gets slightly more weird, I was exporting with DP XD2s selected so I then turned off Denoising and exported and got this

DO XD2s on the left no denoising on the right.

I will test with PL7 at some time and add the details here.

1 Like

Always, by design.

As for the rest, you have to account for quite a bit: you’re not sufficiently correcting CA, demosaic/denoise alters pixels, and JPEG conversion alters pixels. Some color shift has been observed in various cases, and DxO support is interested in those cases. But I think CA still needs to be treated as CA and fixed using the proper adjustments in software or changes to your equipment.

Long story, and once again I agree.

The preview engine must be completely rewritten or at least enhanced so that CA correction, lens softness, sharpening are ALWAYS correctly rendered at every zoom level.

I have been saying this for 3 years now, and nobody listens.

4 Likes

please advise which downscale and upscale methods are correct when you step down or above 100% ? because to render something ALWAYS correctly going down/up from correct 100% zoom you need to agree on that first

@Egregius I could avoid any CA in my images if I refrained from taking photos during late Autumn, Winter and much of Spring of course. The lens is a long zoom and suffers from the issues that plague such lenses but CA is not one that it is “renowned” for!

My concern over my CA settings are because it came from a group of tests as follows

and was the first in the group which had been left with rather extreme settings

image

You also seem to have ignored one of my most important observations, namely that DxPL adds CA, in fact a lot of CA, to the image between 25% - 74% magnification. No amount of technique, or equipment changes can alter that, it is all DxPL.

As for the Loupe issue it appears to be a situation that is also in PL7 with the NR Preview window and PL8 with the Loupe, the choice of DP XD or DP XD2s adds CA to the preview windows to some extent and also to the exported image.

I consider all of these issues to be a consequence of how DxPL handles images with any CA, this is the output from GemStone with minimal edits

Plus at the extreme setting in DxPL we have this happening with someone’s red coat, Gem on the left and PL7.6 on the right

@Egregius we are not talking about some colour shift we are talking about major changes to the image which make a nonsense of the editing process. These are not nuanced changes these are big changes and simply should not be there.

DxO seems to “hide” behind the 75% setting as if it excludes all issues with sharpness, noise reduction and CA! I can accept that barrier allows for the image not being sharp, with no noise reduction and no CA adjustment, i.e. as it was shot but not as an excuse to play “fast and loose” with the image representation.

This is an export from PL8 with no adjustments applied

where are the copious quantities of extreme CA that “plague” the preview images, if the image looked like that below 75% that would be fine but it looks like this

At 70%:-

At 75%:-

and without any NR we have a loupe which appears to be accurate

1 Like

The same algorithm which is used by every other RAW editor on the face of the earth, including the now 15 years old Capture NX2 which had NONE of these visual rendering problems at any scaling level. FIFTEEN years ago, with much less powerful PCs, and no assistance from GPUs.

If it could be done then with no performance issues, it definitely can be done today too.

Previous discussion here, with PLENTY of examples:

From my point of view, it would be much better if corrections like CA, sharpness, aberrations were ALWAYS applied no matter the zoom level, so that the image is always completely rendered internally at 100% and THEN downscaled for display, even with a simple adjacent pixel averaging (as opposed to binning) algorithm. No visualization at less than 100% will ever be completely accurate, but it would already be a BIG improvement to what is implemented currently.

May I ask what is the benefit of seeing the CA removed at <75% ? As you get smaller % you lose more detail and hence more CA.

When you export you will have the full CA removal applied.

I don’t see any benefit to wasting computer resources and hence responsiveness just to show CA removed at low %. If you want to check CA then go to 100% and take a look and then move on.

Make sure to check the box pointed out by the red arrow:
Bild vom 2024-10-18 um 10.05.10

@Lucabeer As you might have guessed I agree with this sentiment but my biggest concern is that DxPL is making a “pigs breakfast” of the CA in my images.

Having it accurately displayed at any and all zoom settings might mean that DxO abandon whatever algorithm they are applying to get the sub-75% image render which would (I hope) remove a large part of the problem with my images, i.e. the part where DxPL is multiplying the CA with “abandon” making it difficult to see the whole image while editing.

At the very least the F11 full screen preview should have an option to see a
full rendered image.

I want to see trees “naked” in my photos not clothed in some purple gown.

@KeithRJ The issue is less about me complaining about the CA not being removed below 75% it is about DxPL actually multiplying the CA and creating a wholly unreal image, i.e. take an image with a bit of CA, multiply that by a factor or ? and present that back to the user to “help” with editing.

As with all things if it transpires that to remove CA in real time is a real problem, and it doesn’t appear to be for other software, then make it an option that users can toggle on and off based on the power of the hardware at there disposal.

The real problem is the application of NR in real time and I can tolerate the Loupe for that but sharpness and CA for the whole image are possible in real time (at least for other packages) and for an increasing number of users waiting a second or two to get the whole image rendered and de-noised in real time on demand would be a real advantage.

Make such a capability so that it can be toggled per image, or for those with deep pockets (for more powerful machines) make it “sticky”, i.e. on until the user selects off.

@platypus Have I selected the correct button, I think I have and this is an image at 26%

PS:- Sadly it took me some time t realise that what I was seeing while editing wasn’t real but a pigment (figment|) of some coder’s imagination.

1 Like

Have you seen the photos that have been posted? If it’s not removed, it causes artifacts that are WORSE than NOT correcting it.

Really, if you have seen these photos and consider this behaviour normal, I don’t have nothing more to say…

2 Likes

Exactly, as said many times. And yet there’s always someone who says “I don’t need it”. What’s the problem in a feature that can be turned off or on, with no damage to anyone, but a lot of benefit for those who care and have eyes that work?

And I’ll repeat it for the umpteenth time: Capture NX2 had no such issues with the much inferior processing power of 15 years ago, and no other RAW converter has them nowadays.

So, why should it be a processing power limitation?

And I will also add, as I have proven in the linked discussion, that it’s NOT only a problem with CA: even with images that do NOT have CA to start with, it happens anyway with fine contrasty structures like your branches. It’s not an issue only with CA: it’s some sort of cheap shortcut in the rendering engine at 74% and below, period. These are artifacts due to bad rescaling, plain and simple.

Further proof (as if needed after all the evidence that has been posted…), a shot out of my window right now. Nikon Z6 and Z 105/2.8 MC: a macro lens which almost doesn’t have any chromatic aberration.

With CA correction ON at 70%:

With CA correction ON at 75%, notice how the reddish hue disappears:

With CA correction OFF at 70%:

With CA correction OFF at 75%:

Is this enough proof that it’s not only a problem of applying CA correction at zoom levels below 75%, but there is something really wrong with the approximate rendering below 75% regardless of CA? There is NO difference between the images with CA correction on or off. The only difference is the zoom level: that unacceptable reddish hue (and the softness) appear anyway at zoom levels below 75%.

2 Likes

And this on the other hand is with the plain humble and free NX Studio:

At 67%:

At 100%:

No difference in color rendition or sharpness. NONE. No red hues, no artifacts. Perfect.

Does everyone trust me that also Capture One works correctly at every zoom level, or do I have to download the trial version and prove it once again?

1 Like

To be honest all users should be concerned about any instance where the presentation of an image, i.e. the visual feedback of an editing decision, are not as accurate as possible.

I and other users have taken to exporting (typically minus NR, unless the the GPU is up to the task) so that we can get a better view and understanding about the editing choices/decisions we have made.

The Loupe helps a bit but a full image equivalent is required and reserve the Loupe for NR examination, other packages handle sharpness and CA on real time so should DxPL.

Looking at an image at 75% and above loses much of the context and I missed the effect that extreme setting of DxPL had on the red jacket because I was concentrating on the problems with the branches! It was lucky that someone with a red coat/jacket was in shot (I normally try to avoid people in my landscape/garden images). Two images with different CA settings

Other packages manage to remove the CA without destroying colours within the image.

So we have

  1. DxPL is adding CA to images between 25%-74% zoom in my case so much that the image looks to be full of CA.
  2. The actual CA removal of DxPL is not the “best” around and to achieve effective CA removal risks using settings that affect other colours in the image! (Please note that the greens are not all they could be in the “black” coat image, and the red coat has turned a shade of near total black, there is still a hint of red!).
  3. The Loupe appears to be accurate and is showing the increased CA that is added to the exported image when using DP XD or DP XD2, i.e. what I thought was a Loupe issue is actually a DX XD and variants issue?

But absolutely NO corruption of the image should occur or be tolerated by users at any level of zoom.

The preview should be enough to achieve a good edit and the user should not have to resort to exporting, except when the GPU is fine for an unattended export but useless for an reasonably instant preview (when the Loupe earns its keep unless DxPL has downgraded the NR to CPU only because of the size of the memory in the GPU!)

PS: - It is downgrading 2GB GPU cards with a message that states that at least 1GB must be available (!?) and why is it downgrading at all when the requirements typically are less than 1 GB when exporting (unless the GPU card is the only source of monitor output, as in the case of my 5900X when it appears to typically take 1GB for basic monito output).

The downgrade means that all processes reliant on GPU activity for rendering for viewing are going to be much much longer.

Why are DxO using such a crude mechanism to handle the issue, wrongly as it transpires (downgrading 2GB cards) instead of evaluating on a image by image, action by action basis.

Sorry that is off-topic but then it is my topic any way and I forgive myself!

I have tested with Zoner, ACDSee Gemstone and FRV (to the screen only) and they all do what they do quickly (on my 5900X) and don’t seem to feel the urge to add more CA.

1 Like

I wholeheartedly agree on every point you made.

And I can assure that it behaves like this even on an 8 GB card anyway (RTX 3070 here).

Checked again, but the issue seems to be specific to the Windows version of DPL.
On Mac, CA correction works as expected.

@Lucabeer Currently the GPU is an RTX 2060 after I swapped the RTX 3060 into a “redundant” i7 4790K to do some export performance testing on that machine and also on this machine (the 5900X).

The RTX 3060 will then go to a 5600G machine for testing before returning to the 5900X and the 2060 will then go back into the 5600G and the i7 will have a rest with a GTX 1050Ti fitted! Who knew what fun “musical” GPUs can be !!

Worse, I have then got to write up the results to bore the forum but then it might or might not help those trying to decide what to buy to make an informed decision.

@platypus Thank you for confirming that.

I presume that the 75% threshold applies to the Mac as well as to Windows, minus the extra helping of CA , of course, as you indicated.

and which one exactly that will be ( apparently you have access the to code of “every other RAW editor on the face of the earth” ) ? there are many, they are all different and they produce different - if you compare all image area pixel by pixel - results when you downscale or upscale from identical 100% view ?

I have access to the RESULTS of most other editors on the face of the earth, having tried them. And that is enough to say objectively that the examples of visual artefacts posted above are unique to PL, and unacceptable. No viewer of no other RAW editor alters the colours at lower zoom levels that way, with those reddish haloes “invented” by the software even when CA is NOT present. None. If you have proof of the opposite, show it here.

You don’t see these artifacts? Ok, that’s fine, but better check a good optometrist then before replying to a post saying that for you this kind of rendition which alters colours is fine and does not require improvements/a bugfix to the viewer. The images are the proof, they can be seen by everyone, and the difference is not subtle. We have posted dozens of images with issues of this kind. How many have you posted to deny it’s an issue?