Ballooning - the hard way

[Manfred M]

We had Cristina Vellejos, a first time model, and a pile of red, helium filled balloons and a red party dress. Add some black seamless paper,a couple of studio lights and lots of Photoshop work.

I've updated the image as I ran into some problems in the ProPhoto to sRGB conversion for posting on the web. The image was fine as a ProPhoto image, but I ran into massive OOG (Out of Gamut) issues when I turned it into an sRGB JPEG. This is the reworked image and the colours are nowhere nearly as vibrant as the original.

[NorthernFocus]

Well it turned out interesting. Something looks odd about the lighting on the dress. A bit too flat. Like there was clipping on the highlights or something?

[Manfred M]

Well it turned out interesting. Something looks odd about the lighting on the dress. A bit too flat. Like there was clipping on the highlights or something?

Conversion to sRGB seems to be the cause. No clipping in the original.

[NorthernFocus]

Conversion to sRGB seems to be the cause. No clipping in the original.

Ah, yes. I've run into that once or twice with really vibrant man made colors.

[Manfred M]

Ah, yes. I've run into that once or twice with really vibrant man made colors.

Me too and it was with vibrant reds that time as well.

I tried both Relative Colormetric and Perceptual rendering intents and there's not much to choose between them so far as final image quality. The 16-bit to 8-bit conversion / JPEG compression add to the problem.

The screen shot from my AdobeRGB screen does not seem to be affected, so I'm going to have to try a few more things.

When I turn on the gamut warning (OOG colours are shown as grey), on converting from ProPhoto to sRGB, most of the reds are OOG.

[RBSinTo]

Conversion to sRGB seems to be the cause. No clipping in the original.

Wait! What?
Ya mean she really wasn't floating because of the balloons?

[Shadowman]

Nice concept.

[ST1]

Thanks for posting these images Manfred, I find it very interesting to see the before and after images and the OOG issues that you've experienced.

I too have had OOG issues particularly with reds. One was a display of ceramic poppies displayed at the Tower of London, it was horrendous to get a decent print from the image.

[mugge]

Red is such a terrible colour to get right. Maybe that is why I prefer B&W
Cheers Ole

[Jim A]

Excellent, Manfred, I really like it all except her lower hand, which seems at an odd angle? Still, I would have been very happy indeed to achieve this.

[TonyW]

This is a nice image but also an interesting exercise in changing colour profiles. I have never understood the way the colour profile conversion works, in particular whether it is a linear transformation or not. I suspect not. The histogram of the sRGB image looks quite different to that of the ProPhoto version in the right had end of the red values which suggests that the out of gamut areas are not treated very well.

I played with the sRBG version that was first posted and it seems if you start with that you can recover some of the vibrancy of the original image with a curves adjustment. Perhaps we should always look at the image ofter conversion and readjust it if necessary. I know I tend to convert and not look at any problems caused by the conversion.

[xpatUSA]

I open all my raw shots in sRGB working space because is that the only output profile I use; therefore, what I see on the screen is what I'll get when exporting. I cast suspicion on any channel which has a lot of zeros in it because any pixel with a zero in it is 100% saturated and 100% saturation is indicative of out-of-sRGB-gamut color. Certainly so for natural colors.

While still in sRGB, reducing saturation usually fixes it for me. If not, I'll export in ProPhoto to RawTherapee ** which, as a few of us know, can fix anything.

https://rawpedia.rawtherapee.com/Color_Management

https://rawpedia.rawtherapee.com/Color_Management_addon

The classic case for guaranteed OOG is when shooting full-spectrum (UV/IR blocker removed); any reflected IR part of the scene (during conversion to RGB) forces the green channel to zero, giving that horrible purple look. Thus, green foliage turns red/brown but skies remain blue-ish.

** I used to be a member of the "I always edit in ProPhoto" set, but now only when in RT because that is RT's native working space.

[xpatUSA]

I too have had OOG issues particularly with reds. One was a display of ceramic poppies displayed at the Tower of London, it was horrendous to get a decent print from the image.

I remember that one, Peter. I may even have mouthed off in that thread ...

[Manfred M]

This is a nice image but also an interesting exercise in changing colour profiles. I have never understood the way the colour profile conversion works, in particular whether it is a linear transformation or not. I suspect not. The histogram of the sRGB image looks quite different to that of the ProPhoto version in the right had end of the red values which suggests that the out of gamut areas are not treated very well.

I played with the sRBG version that was first posted and it seems if you start with that you can recover some of the vibrancy of the original image with a curves adjustment. Perhaps we should always look at the image ofter conversion and readjust it if necessary. I know I tend to convert and not look at any problems caused by the conversion.

The only place I ran into issues on this image is when I converted to sRGB so that it could be displayed on the web. I normally prepare all my work to be high quality print capable, so that means a minimum of Adobe RGB colour space, preferably ProPhoto RGB. The problem with sRGB is that it does not include the vibrant colours found in Adobe RGB or especially in ProPhoto RGB, so the solution has to be to reduce the vibrant, saturated colours.

The problem with the initial post is, I suspect the way that the out-of-gamut (OOG) colours were handled. One common way of doing this is to take all OOG colours and assign them a value that just brings them into gamut (i.e. Relative Colormetric rendering intent). The issue with this approach is that one will lose any sense of texture at all and I suspect that is what happened in the original version. Going with a Perceptual rendering intent is supposed to map all of the OOG and in-gamut colours evenly, but that does not appear to have happened when I tried that rendering intent and I'm not sure why.

In the end, I went back and reduced the vibrance using Photoshop's Proof Setup and Gamut Warning functionality. That's very much the same approach I use when preparing an image for print.

[Manfred M]

I open all my raw shots in sRGB working space because is that the only output profile I use; therefore, what I see on the screen is what I'll get when exporting. I cast suspicion on any channel which has a lot of zeros in it because any pixel with a zero in it is 100% saturated and 100% saturation is indicative of out-of-sRGB-gamut color. Certainly so for natural colors.

While still in sRGB, reducing saturation usually fixes it for me. If not, I'll export in ProPhoto to RawTherapee ** which, as a few of us know, can fix anything.

https://rawpedia.rawtherapee.com/Color_Management

https://rawpedia.rawtherapee.com/Color_Management_addon

The classic case for guaranteed OOG is when shooting full-spectrum (UV/IR blocker removed); any reflected IR part of the scene (during conversion to RGB) forces the green channel to zero, giving that horrible purple look. Thus, green foliage turns red/brown but skies remain blue-ish.

** I used to be a member of the "I always edit in ProPhoto" set, but now only when in RT because that is RT's native working space.

Ted - that may work for you, but as someone who prints, I'd rather stay in the wider colour spaces that my printer can handle and then downsample the image for display on the web. My workflow generally works well that way as I rarely have an image with so much material that is OOG.

[xpatUSA]

Going with a Perceptual rendering intent is supposed to map all of the OOG and in-gamut colours evenly, but that does not appear to have happened when I tried that rendering intent and I'm not sure why.

It is well-known that matrix-type profiles cause the opening app to ignore any 'perceptual' tag, instead providing relative colorimetric.

Only profiles with CLUTs will give 'perceptual' transforms.

I'm thinking that surely you already knew that?

[Manfred M]

It is well-known that matrix-type profiles cause the opening app to ignore any 'perceptual' tag, instead providing relative colorimetric.

Only profiles with CLUTs will give 'perceptual' transforms.

I'm thinking that surely you already knew that?

Yes, but that only applies to a display based conversion run by the OS.

When the conversion is done by the photo editing program, it has its own rendering intent handling as part of the RIP (raster image processor) functionality.





All of the OOG examples I show in this thread use this functionality to show the OOG areas in grey.

[xpatUSA]

So, in your opinion, A matrix-based ICC profile can actually result in a perceptual output?

[Manfred M]

So, in your opinion, A matrix-based ICC profile can actually result in a perceptual output?

Your assumption is that all rendering intents are matrix based? This is not correct, so far as I understand it. The OS might implement this way, but RIP software does not. In fact one of the key selling features different RIP software is the way that Perceptual rendering intent is performed, with different users preferring one vendor over another.

Relative colormetric, on the other hand, has a common approach.

[xpatUSA]

Your assumption is that all rendering intents are matrix based? . . .

No Manfred, I neither said nor assumed that at all!

. . . This is not correct, so far as I understand it.

Quite right: "all rendering intents are matrix based" is definitely not correct!

The OS might implement this way . .

It might indeed, but I was referring in particular to ICC profiles commonly embedded into image files and that any application that can open, not just the OS.

I would say that many, if not most, of the images posted here have embedded matrix profiles typically 5-10kB as opposed to ones with CLUTs up around 200kB.