@elle is amazed that people are still interested in her image. And also happy, as @elle is learning lots
Regarding the white clouds, there really is no clipping. But depending on the white balance multipliers, some RGB channel values in the clouds will be pushed over 1.0f unless you apply some negative exposure compensation.
For example in darktable using a white balance of “tint: 0.940” and “temperature: 5214K” plus other settings as per this XMP file which produces a strictly scene-referred output lacking any “make it pretty” edits:
080724-1822-100-1479.cr2.xmp (28.8 KB)
then after opening the image in GIMP, these pixels marked in red have channel values >1.0f:
All it takes to bring the channel values down below 1.0f in GIMP is “Colors/Exposure” using “Exposure: -0.130”.
Of course if one outputs to disk as integer instead of floating point (or in the current case, sends floating point values directly to GIMP using the darktable plug-in), then the exposure compensation would need to be done in darktable or else the >1.0 channel values would be clipped on export.
One of the things I really like about GIMP floating point processing is that I don’t have to worry about making sure in the raw processor to precisely dial in exactly the right amount of exposure compensation.
Regarding the lack of detail in the indicated areas of the clouds, there really isn’t much detail there. This isn’t a matter of low resolution but simply because as @RawConvert notes, sometimes areas of white clouds just don’t have much tonal variation. The thing to be wary of is that “make it pretty” processing in the raw processor - even sometimes including highlight recovery - can easily obliterate such detail as is actually there. And of course the desire to intensify contrast in the clouds pushes the brightest portions to white, again obliterating such detail as is actually in the raw file.
I did check all three channels to be sure, and there really wasn’t any clipping at all. So I turned the image to black and white, and applied an extreme Curve, letting the foreground go to solid black, producing the top image below - any clipped pixels would still be solid white. Then I did “Auto Stretch Contrast” and tried to locate the brightest pixels in the two bright areas in the clouds:
One thing I’ve learned from the various interpretations of this departing storm image is that the brownish rectangular patch in the lower right corner is actually briars and branches instead of a smeared area from stuff on the car window. The ability of our free/libre raw processors to pull detail from almost nothing is amazing.
An interesting aspect I hadn’t really noticed before is that there are essentially no shadows in this image. The only “for sure” shadow I could locate is under the large tree behind the building on the left side of the image. That shadow is faint and just under the tree, no directionality, as if relatively diffuse light is all coming from above.
If @CriticalConundrum hadn’t mentioned Albert Bierstadt, I wouldn’t have noticed this lack of shadows. Bierstadt uses color changes in areas that are sunlit vs areas that are still in shadows to indicate sunrise, departing mist, stormy vs clear areas. But lacking any clear indication that any particular portion of my departing storm image is actually getting direct sunlight, where in the image would one deliberately and belieavably change the “color of the light”? The only “clear blue sky” portion of the image is the actual clear blue sky. The sun is still somewhere behind the clouds, otherwise there’d be clearly defined shadows in portions of the image.