PL7 Shadow Banding

I believe that this was also a problem in PL6, but there is excessive shadow banding when lifting exposure compared to other RAW processors.

Attached is the same raw file processed in PL7.0.2 and in CaptureOnePro23. The shadows have been lifted about 4 stops to make the banding more obvious. In COP, the image is completely clean.

Again, 16 bit GFX100s RAW files.

just a regular note - you might want to share a raw file that can help people to try to investigate the problem if it is not very obvious …

1 Like

Also the .dop file might be helpful.


1 Like

Looks like gradient discretization.

Are you using Wide Gamut, or the older standard gamut?

With Wide Gamut, I have never encountered this issue.

Is that with DeepPrime/XD?

Attached is another image, pushed further to exaggerate the banding:

In response to some of the replies:

  • this occurs with any GFX100s 14 or 16 bit RAW with substantial shadow lift
  • to be visible, it needs an area of the image that is very dark (eg a cloudy night sky), which makes the banding obvious
  • settings for exposure, noise reduction, vignetting/lens-corrections etc modify the banding pattern but do not eliminate it
  • it is possible to see the banding with all corrections off except for exposure and a shadow lift
  • it is not affected by how the image processing is performed (GPU, CPU, etc)

This only happens with very large exposure corrections (typically 4 stops), but when it happens it is very visible in shadow areas. It does not happen with Adobe RAW or CaptureOne converters.

Normally, you would not push the exposures so much. But the GFX has essentially two sensitivities, at ISO100 and ISO500, and is otherwise fairly ISO invariant. This means that for high contrast night shots, rather than lifting ISO in camera, it is often better to deliberately under-expose and lift shadows in post-processing (thereby preserving highlight detail that would otherwise be lost). It only affects a small number of images where you are trying to process something with very high contrast, but when it does, it is very obvious.

My guess is that this is not a ‘bug’ in the usual sense, but instead a bottleneck in the DxO image processing pipeline. It looks as if there is a processing stage where data is being clipped to ~12 bits, which would explain why I do not see this with Olympus images (ie the Olympus RAWs are themselves only 12 bits).

I can post a raw file, but be aware that it is ~100MBytes in size. However, there is no image processing adjustment that will avoid the problem (you can turn all corrections off except for the exposure). It is something that needs to be looked at by DxO.

That’s why I was asking if you are using Wide Gamut!

1 Like

Changing the working colour space (Wide/Classic) does not change the banding pattern, although it does slightly change luminosity.

1 Like

Weird then, because theoretically the pipeline has been entirely reworked for Wide Gamut to give more precision.

Frankly, on my Nikon bodies (D700 and Z6) I have never seen such artifacts, except ONCE when I was using a lens without DxO profile on PL3: I had used manual vignetting correction, and it gave somewhat similar results to what I am seeing here (but MUCH less severe, nonetheless).

what a wider gamut of that color space has to do with any math precision and with colors that were not outside even sRGB gamut for a start ?

It has to do with the fact that DxO rewrote the whole processing engine when they introduced Wide Gamut, and according to what they have explained, with that rewriting all the internal calculations are now done at 32 bit precision. So that makes it even more unexplainable.

In theory, a Wide Gamut would even be WORSE in terms of posterization than a restricted one like sRGB (=more colors to be represented with a limited number of bits). But at 32 bits it really shouldn’t matter.

you need to post raw file if you want people to stop making guesses and actually attempt to investigate


J’avais régulièrement ces traces en auréoles sur des fonds unis (ciels bleus…) en traitant mes raw issus d’un Sony NEX7, je crois me souvenir qu’il s’agissait alors de PL5. Comme je voyais aussi parfois le même genre de traces sur des images vidéos reçues sur ma TV (Sony Bravia), j’en avais conclu que le problème se trouvait chez Sony et ses capteurs de format APS-C qui sont très courant chez les filmeurs documentaristes.
En tout cas je n’ai plus jamais eu ce problème avec mon Nikon Z plein format.

Where did you hear about 32 bit precision? I think I remember that they could not integrate HDR, as the image pipeline would not support 32 bit.

OK, do you mind to provide a link talking about “32 bit precision” please ?!

I checked = DxO Wide Gamut : une révolution haute en couleurs - DxO – no

I checked = DxO's new ultra-wide color space is unique - DxO – no

I checked = – no

may be I missed something, please do correct me - much appreciated, thank you !

1 Like

My mistake. I double checked the old messages from the EA program (private internal forum for betatesters).

The Wide Gamut pipeline is 16 bits per channel (so 48 bits total). Which still should be enough not to cause any posterization.

again, just share the raw file … if somebody is going to dig in - that person needs the actual bits and bytes

1 Like

I am happy to put the RAW and DOP files online for DxO to take a look, but I can not upload a 100MB RAW file directly to this thread.

In any event, it is trivial to reproduce with the GFX100s - just under-expose and push the exposure. Maybe it is something specific to the RAW processing for that camera. But it is not a problem with the camera itself, because the same RAW file processed in other converters does not show the banding.

Re the lens profiles, this image is indeed one with a lens for which there is currently no profile. However, the problem occurs also with fully supported lenses. Enabling and disabling the lens vignetting and distortion changes the pattern of the bands. Disabling both corrections gives the same result as deliberately deleting the lens profile.

just link to any file-hosting service is OK