Plug-In: PercepTool 2

[Doug Nelson]

PercepTool 2 is an HDR plugin for Photoshop that comes with a couple of very unique features: George DeWolfe and Chris Russ. George is a master printer who has made the rare successful transition from darkroom to digital. Chris is one of the most respected technical imaging engineers in the business (and not a stranger to these forums).

Anyway, Chris emailed me and asked for feedback on PercepTool 2. Download the trial, kick the tires, and post back here with your findings.

http://www.georgedewolfe.com/perceptool.html

[mistermonday]

I have been doing considerable benchmarking of various HDR S/W recently so I took PercepTool for a spin on some of my bracketed test image sets.
My 1st and probably most important test is how the s/w handles highlights. If it fails there, then all of the fancy interfaces and presets, and frills don't matter. At that point the testing is pretty much over with a failing grade. There are ways to work around the problem, but a lot more work and fiddling is not what I am looking for.

The good news is that PercepTool gets a pass. It is not as good as Photomatix which I find superior to the all others including Nik's HDREfexPro, Oleono Photoengine, and PhotshopCS5's Merge to HDRPro with PS being by far the worst. PercepTool comes pretty close to blowout of the highlights but just manages to keep it from hitting the top limit. However compared to Photomatix it does wash out a fair amount of the detail in those highlights.
I was not particularly impressed with the shadow detail. I found the shadows too dark and lacking detail. Performance here was about middle of the pack.
Noise performance was good. The best noise performance by far was Nik HDREfexPro followed by PercepTool.
I do not like the way the program is chopped into 3 pieces and the fragmented workflow:
-Run the PS script to open and load RAW files into a stack or process each image your self then load and stack.
- Run the HDR blend / tonemapping with no controls or adjustments
- Run the Equalizer Filter
- Run the PercepTool filter to do Gamma, Exposure, etc (most people would prefer to do this stuff in PS).
I can post a few image comparisons if you like.
Regards, Murray

[Doug Nelson]

Did you get to try it in 32 bit? I suspect that's where it shines (and kind of the reason they wrote it).

[mistermonday]

I had PS open and stack 5 aligned RAW files (16 bit NEF) and then ran the HDR Filter on them. The resulting default image was the test point. I did not convert that to 32 bit nor should I have had to. Or am I missing something?
Regards, Murray

[Doug Nelson]

As I understand it (and I'm not promising that I do), it's not that you have to, but that finally you can. That's one of the reasons I wanted to get it into the hands of some experienced HDR fans, to see if 32 bit actually makes that much difference.

[mistermonday]

The 32 bit file is produced by the HDR merge. Most HDR s/w uses this 32 bit file as an interim file which it discards after performing the tone mapping to an 8 or 16 bit output. Most of the s/w also gives you the option to save that 32 bit file as well so that you can play with it in PS or other s/w.
The issue is that the initial merged default image produces unsatisfactory results. I can process the resulting 16 or 32 bit image in PS or in PercepTools Equalizer or a umber of other s/w options. However that is not what I want to do. I am looking for a merge that gets the image to where I need minimal tweaking and do not need to spend time recovering blown highlights or enhancing shadow details. So far Photomatix is the only product I have found that does that and it does it almost 100% of the time. The other products so all fail at the 1st and most critical point.
Regards, Murray

[jcr6]

Oh, where to begin.

I'm one of the authors of PercepTool. As you've observed above there are indeed three parts, and I'd like to outline them, what they're for, why they are separate, and the advantages of 16- and 32-bit modes respectively.

Let's start with HDR Align and Blend.

One problem that I encounter as a photographer is alignment of my images, even when taken on a heavy duty tripod. If you are going to perform HDR, you either must align the images manually, or depend upon the software to do a good job. I discovered, much to my chagrin, that Adobe's alignment results are inconsistent. Even with the same images. So the first part of HDR Align and Blend is designed to solve the alignment problem -- we align several times (user selectable) and pick the best fit. The stack of images is then nudged to match.

You could stop right there and use some other tool if you wanted, or you could continue on with the Blend part and we produce a really acceptable HDR blend that pays close attention to color, especially in the midtones. In the head-to-head comparisons that we did, we had a much more faithful treatment of color and saturation than did the other tools out there (remember, I'm the guy that wrote it, so you really should test it yourself). And as is common to HDR images blended in this way, they tend to lose saturation in the highlight areas and we did something to address that (Color Correction).

I also put a lot of effort in to making a low-noise result. The first version of HDR merge in CS2 kept the pixels that were MOST DIFFERENT than their neighbors -- essentially a noise detector. If your image has lower noise, you can perform more sharpening or other steps. If it has higher noise, there are very few things that can be done to an image to make it better.

The kicker is that we did it in 8- (works, but not recommended), 16-, and 32-bit modes. Doesn't seem like a big deal.

Q: Why 32-bit mode? A: Because out-of-gamut colors don't clip. Because your highlights won't go away during processing.

A lot of people poo-poo 32-bit mode but it does have that tremendous capability of preserving your highlights, colors, and detail within those highlights so you can decide later how to adjust the image and bring everything into a more narrow dynamic range for printing.

HDR Align and Blend is scriptable and actionable -- you can record it for your own secret sauce. You don't have to use the whole thing. THAT is the point about breaking PercepTool into different pieces, because none of us like to be dictated to.

-----

The Equalizer tool.

This is a unique multi-scale contrast (tone-mapping) tool. You don't have to have an HDR image to use it. It does really nice things for normal photography, but can be especially useful for HDR Photography where you have to deliberately throw away parts of your image to see other parts. The whole point of dynamic range reduction is to make an image that shows the important (to you and the viewer) parts of the image while eliminating or reducing the parts that don't matter. The kicker is doing it in a visually believable way.

Remember, we have two different parts to the human visual system and they don't work the same way:
1) The peripheral visual system basically makes a gross luminance (and some color -- not much) map of the whole image, and the resolution drops as you get farther from the center of your field of view
2) The central visual system (also called the Foveal visual system) is about the size of a thumbnail at arm's length and is the high-resolution part of your visual system. Basically people look at different things and "hang" those high resolution bits on the overall gross luminance map. Our brains make these pieces seem seamless, and we're quite good at assuming details that we never actually looked at because we recognize familiar objects and move on. (This is one reason that JPEG compression works.)

Any tone mapping (or contrast) tool is going to need to work well with both systems. Sadly, tools that work well with the peripheral system tend to leave lots of halos. Tools that work well with the central system don't deal well with gross brightness changes across the field. In my experience, halos and the 'grunge effect' aren't acceptable if you're trying to make a believable image.

The era of 'grunge' HDR photography is coming to a close, and tools that leave nasty halos behind are going to have to go with it.

The Equalizer is designed to affect seven different size ranges, two with radii over 2000 pixels -- something you cannot do in Photoshop or any other tone mapping tool. Something that is essential if you have a high resolution image and don't want to see a halo. For those interested, there is a book called "Vision" by David Marr that might be interesting.

It is also completely scriptable and actionable and you can record settings to put into your own secret sauce for processing images.

-----

Finally, there is the PercepTool.

PercepTool uses the primary image's display, not a proxy view, and is designed to bring back the "punch" in images. Very literally, What You See Is What You Get. Not only does it do a halo-free sharpening as part of the PercepTool Effect, but it also uses a very non-linear method of finding local shadows to bring "presence" back to the image -- to make it more like the scene seemed when you took the picture in the first place.

There certainly isn't a requirement that the image be from an HDR source, but it can work quite well on those images. And, if you are working in 32-bit mode, you can get a histogram of your image, something that Photoshop will not let you do.

-----

There is a lot of stuff here. Some or all of the pieces might fit into your workflow into a number of places, whether you shoot HDR or not, whether you find 32-bit mode useful or not, whether you have CS4/5 Extended or Normal.

This wasn't written in a vacuum and the functions are not so simple that someone can come along and say "Oh, it's just _blah_blah_blah."

That being said, with a 30-day demo period, you can find out for yourself if there is any "there" there.

(Sorry to go on for so long, but I couldn't leave things the way they were upthread.)

[mistermonday]

JCR6, thanks for the additional information on PercepTool. As mentioned above your noise performance is very good and in most your ability to retain highlight detail is better than any product I have looked at except Photomatix. I agree with your comments about the grunge look soon becoming a fading fancy, and I don't think that is what HDR is all about. My biggest concern has been and continues to be blown highlights upon merge to HDR. I have attached a sample below of PercepTool and Photomatix. To be fair, no adjustments were made to the RAW files, no sharpening, no denoise, no Chromatic Aberation mitigation, etc. No post adjustment were made to either file after merge. The images were converted to sRGB for browser view and are low res but the areas of concern can be readily seen.
You will see a clear difference in the bright highlights which have been almost 100% preserved by Photomatix. PercepTool has pushed them pretty high and where they are not blown, the detail is reduced. There are no control options prior to or during merge and I am finding it very difficult or impossible to make correct for it after merge using Equalizer or PS. I could modify the RAW files or I could exclude the overexposed ones but that would not be an effective way to work. I would welcome any thoghts you might have in this regard.
I did not attach any samples of the shadows. They are definitely darker than Photomatix but the shadow detail can still be recovered so I am not too concerned.
Regards, Murray

[jcr6]

How do you feel about the color rendition in the Photomatix output?

--------

It is difficult to be fair to you and your aesthetic, while at the same time trying to point out where I consider the PercepTool result superior.

Personally, I consider pumping up the saturation a late processing step, largely because colors can easily go out-of-gamut. (We should talk about 32-bit images sometime.) I also see some colors rendered in the Photomatix image (magenta in a blue-white highlight) that don't appear to be real. Not having the original images, it's hard to comment, but to me color fidelity is an issue. Photomatix problems with color showed up in our testing.

You did say something upthread that seems to summarize the difference between your approach and mine: You want a one-stop "do-it" kind of tool. There is absolutely nothing wrong with that.

Me, I'm a Photoshop junkie that likes control. I record my own actions or scripts with the steps that I like and with PercepTool 2 I tried to provide a bunch of tools for people that like that level of control. Some of my users spend a lot of time on each image, per George's workflow.

The PercepTool suite is intended to add to a Photoshop user's tool set. It's not just for HDR, but does a good job of HDR when you want to.

HDR isn't the whole story -- the Equalizer draws from Edward Land, David Marr, Jean Babtiste Joseph Fourier and others.

[mistermonday]

Originally Posted by jcr6

How do you feel about the color rendition in the Photomatix output?

--------

It is difficult to be fair to you and your aesthetic, while at the same time trying to point out where I consider the PercepTool result superior.

Personally, I consider pumping up the saturation a late processing step, largely because colors can easily go out-of-gamut. (We should talk about 32-bit images sometime.) I also see some colors rendered in the Photomatix image (magenta in a blue-white highlight) that don't appear to be real. Not having the original images, it's hard to comment, but to me color fidelity is an issue. Photomatix problems with color showed up in our testing. I agree with your comment on saturation. The saturation control is makes it easy to dial it up or down. There is a strong Chromatic Aberation in the originals and the building is surrounded by water, colored roofs, and other buildings with colored glass. I will take a look at the color pollution but I can also believe that Photomatix may be inducing some of it. BTW, I forgot to mention above that PercepTool was the only product aside from Photomatix that did not induce strong color casts in many merged images. Some of the competitive products strongly shift saturation when exposure or other sliders were tweaked.



You did say something upthread that seems to summarize the difference between your approach and mine: You want a one-stop "do-it" kind of tool. There is absolutely nothing wrong with that.

I am not looking for a one - click tool. I spend a fair amount of time making additional adjustments to get the image right. What I do not want to do is spend a lot of time compensating for blown highlights unless there is no other solution. I used to do a number of things including copying blown pieces from one of the source files and masking them into the merged image or preprocessing the RAW files before merging to ensure the highlights would not get blown. However, if I can achieve a merged file without having to go through that hassle, that is preferable.

Me, I'm a Photoshop junkie that likes control. I record my own actions or scripts with the steps that I like and with PercepTool 2 I tried to provide a bunch of tools for people that like that level of control. Some of my users spend a lot of time on each image, per George's workflow.

The PercepTool suite is intended to add to a Photoshop user's tool set. It's not just for HDR, but does a good job of HDR when you want to.

HDR isn't the whole story -- the Equalizer draws from Edward Land, David Marr, Jean Babtiste Joseph Fourier and others.

The PercepTools are definitely impressive and I can see their value as part of the PS tools set. I think if your algorithm were refined to preserve the highlights a little better you would have a more successful product

Regards, Murray

[jcr6]

I appreciate your candor. I clearly misunderstood your position re: highlights.

Just wanted to leave you with a silly notion -- what happens if you take that Photomatic image and use the luminosity from it, but use the color/saturation from the PercepTool HDR image?

Coming into this, looking at the HDR tools that were around, I really got fed up with the colors coming out of some of the other packages. You make me want to take another look at the effective contrast curve that I'm using to see if I can squeeze more stuff into the midtones, further away from the ends. Although you may find that our results are different if you do the blend in 32-bits rather than 16-. Comes from being in a different number/color space.

Thank you for the feedback. The danger with being vocal on such issues is that people might tap you to be a beta tester.

-Chris Russ

[mistermonday]

Originally Posted by jcr6

I appreciate your candor. I clearly misunderstood your position re: highlights.

Just wanted to leave you with a silly notion -- what happens if you take that Photomatic image and use the luminosity from it, but use the color/saturation from the PercepTool HDR image?

The whole is now better than the sum of its parts.

Coming into this, looking at the HDR tools that were around, I really got fed up with the colors coming out of some of the other packages. You make me want to take another look at the effective contrast curve that I'm using to see if I can squeeze more stuff into the midtones, further away from the ends. Although you may find that our results are different if you do the blend in 32-bits rather than 16-. Comes from being in a different number/color space.

At the rate things are going, PS and other apps may be fully 32 bit sooner than we think.

Thank you for the feedback. The danger with being vocal on such issues is that people might tap you to be a beta tester.

I have on occasion been called a beta nerd. Always willing to help make good things work better

-Chris Russ

Regards, Murray

[jrp]

I am always on the lookout for plug-ins / scripts for improving tonal rendition.

Unfortunately I did not get far with Perceptool for two main reasons:

• The installation requires fiddling with UAC, which involves rebooting, which no other plug-in that I have come across requires
• The price -- $150

For $150 we are in overpriced, but capable, Nik software plug-in terroritory. The various Topazlabs tools and ContrastMaster or even the full Lightzone are much more competitively priced and have a support ecosystem. You can get the likes of ALCE or the various PSKISS tools (which use the GPU for extra speed) for 20% / 5% of the cost of Perceptool, and they install without too much hassle, and have more tutorials, which in my view are part of what I am paying for.

I have no affiliation with any of the above, I though that it might be helpful to offer the views of a potential customer.

[mistermonday]

JRC, the installation is quick and does not require any fiddling or reboot. Did you do a File>Scripts>Browse or some other method?
Regards, Murray

[jrp]

I did (on Win 7 x64) and it came up with a dialogue box saying that I needed to turn off UAC.

[jcr6]

jrp is right -- some windows systems are so locked down that even if we're launched from Photoshop we STILL cannot install. UAC has to be briefly turned off.

I *HATE* Vista and Win7.

In any case, once it is done you can turn UAC back on. I'm sorry it is that way, but it also shows that even though Adobe has supposedly been given permission to write files WITHIN ITS OWN FOLDERS, it still isn't allowed to.

Seriously. Our installer is just a Photoshop script. You'd think that File > Scripts > Browse would just work. But it doesn't.

re: Price. It takes a certain amount of return on investment to get a programmer to write something. I'd NEVER get the value of my time back if I sold it for $6 (like PSKISS). And I'm not the only guy that worked on this.

re: Value for the price. I guess you'll have to try it. The demo is good for a MONTH. No watermarks.

[andrewrodney]

Q: Why 32-bit mode? A: Because out-of-gamut colors don't clip.

Ah, the bit depth of the image has zero to do with gamut clipping.

Higher bit depths are “useful” for wider gamut color spaces because the colorimetric distance between bits in a higher gamut doc is greater than a lower gamut doc. But this isn’t a gamut clipping issue, its a means of avoiding banding when editing wider gamut data.

As for the rest of the HDR discussion, I’ll sit back and learn...

[Doug Nelson]

I don't pretend to know anything about this, but in the Chris Cox show I did he mentioned that it's not the 32-bit part that's important by itself, but that 32-bit uses floating point.

My head hurts already just from typing this.

[jcr6]

Andrew.

Actually the bit depth has EVERYTHING to do with gamut clipping. You see, in 8- and 16-bit modes, once you're at max value (255 and 32768, respectively) that's all the channel can hold. In 32-bit mode the normal working range is 0.0 ... 1.0, but in theory we can go all the way up to 1e38 and go negative as well (in practice, I've never tested 32-bit mode over 2048, and routinely use negative values to make the layer modes useful). But your values do not clip. This means that you can represent an extremely red value (say the equivalent of 290,10,1) without it being clipped in a channel (say to 255, 10, 1). This means that you can SHARPEN your highlights without clipping the luminance.

Banding is a side-effect of insufficient precision. Precision is why 16-bits is a better space than 8. BTW, in 32-bit mode, you have a 23-bit mantissa (the rest is used for the sign and the "floating" decimal point), which is wildly larger than Adobe's 15 bits in 16-bit mode and the paltry 8 in 8-bit mode.

Furthermore (and you can test this yourself), when you step down from 16-bits to 8-bits, Adobe adds 1/2 a bit of noise to prevent banding -- to break up the patterns that might appear. Going from 8 -> 16 -> 8 does not leave you with what you started.

Now, with the exception of some astronomy cooled-ccd cameras and some funky digitizers, most cameras produce AT BEST 12-bits (typically in the Red channel, and you're lucky to get 8 or 9 real bits of information in the Blue channel, with Green being inbetween -- silicon likes Red and Near Infra-Red, not Blue). So unless you want to represent a large dynamic range and protect yourself from going out of gamut or clipping, I'd really argue that Adobe's 16-bit is quite sufficient for the following reasons:

1) Half as much data == at least twice the processing speed (sometimes a lot faster depending upon the amount of RAM in your computer)
2) Still enough bits to represent anything you've got
3) Nearly all of Photoshop works in it
4) You can print

Although I'm still waiting on a better-than-8-bit display.

(BTW, our HDR does a pretty nice job in 16-bit mode, and doesn't use a 16-bit internal image, unless you're processing in 32-bit space.)

Reasons to go 32-bit:

1) Masochism.
2) Protecting your highlights (so you can process your image without losing them and decide later what to do with them)
3) Protecting your colors
4) HDR fidelity
5) Fourier processing. (Consider the carrot dangled.)

Since it is an obvious hole in Photoshop's functionality (just like CS was seriously lacking in 16-bit functionality), that's where I've put my effort. CS2 tried to make 16-bit mode an equal partner. It is only a matter of time before 32-bit floating point becomes a near-equal partner.

Reindeer will definitely be producing more tools to work in 32-bit mode.

[Doug Nelson]

Couldn't find a Fourier carrot, but here are some Mandelbrot cauliflower:

http://www.google.com/images?q=romanescu

But seriously, folks, is there any Fourier processing of interest to image retouchers outside of pattern reduction? And does 32 bit help there (beyond theoretical)? Does HDR introduce any regular patterns?

[jcr6]

Focus correction.

HDR might introduce an emphasis on any sensor pattern. Remember the R,G, and B components aren't really at every pixel. The demosaicking process can leave funky artifacts. But that's a stretch to think we can fix it that way.

However, that does argue that HDR should be done with DNG images and the original, uncorrected sensor values. And we demosiack after the fact.

Now MY brain hurts.

[andrewrodney]

You see, in 8- and 16-bit modes, once you're at max value (255 and 32768, respectively) that's all the channel can hold.

I respectfully suggest you understand what color gamut is vs. the number of bits for encoding said colors (gamut). Again, the bit depth has zero role on the color gamut. You can have an 8-bit (or 16-bit or even 32-bit sRGB document). The same can be true for a ProPhoto Document. The gamut is entirely different.

http://www.adobe.com/digitalimag/pdf..._colspace.pdf:

When you work with 24-bit images, all color and tone is defined in three 8-bit color channels. When you work with wide gamut working spaces, the same bits need to be spread farther apart over the entire color space. Consider this spreading of a finite number of bits as follows: Imagine you have a half-inflated balloon that has 16.7 million dots evenly spaced over its surface. Now you blow up the balloon to twice its original size. Each dot is spread farther apart. When you work with 8-bit-per-channel files, you create this effect when you encode the bits into a progressively larger gamut working spaces. In such situations, it is possible that editing images will produce banding (aliasing). For this reason, should you decide to use a wide gamut working space—for example, something wider than Adobe RGB (1998)—you should attempt to encode the data in 16-bit color. Many capture devices produce more than 8-bits per color and allow you to retain this extra data to use in Photoshop. While the file size will be twice as big and image processing will take longer, you can’t be too careful with your data. You may also wish to use 16-bit data with smaller gamut color spaces.

And the gamut of a capture device is somewhat fixed (in reality, a digital camera has no gamut but rather a color mixing function) yet the facts remain, adding more bits doesn’t extend or enlarge the gamut any more than converting an sRGB document from 8-bits per color to 16-bits per color adds any gamut to the data. It adds more bits but does not extend the color gamut as expressed on some kind of gamut plot (xy chromaticity diagram).

Precision is why 16-bits is a better space than 8.

Agreed. But that has nothing to do with color gamut.

[jrp]

Originally Posted by jcr6

jrp is right -- some windows systems are so locked down that even if we're launched from Photoshop we STILL cannot install. UAC has to be briefly turned off.

I *HATE* Vista and Win7.

In any case, once it is done you can turn UAC back on. I'm sorry it is that way, but it also shows that even though Adobe has supposedly been given permission to write files WITHIN ITS OWN FOLDERS, it still isn't allowed to.

Seriously. Our installer is just a Photoshop script. You'd think that File > Scripts > Browse would just work. But it doesn't.

re: Price. It takes a certain amount of return on investment to get a programmer to write something. I'd NEVER get the value of my time back if I sold it for $6 (like PSKISS). And I'm not the only guy that worked on this.

re: Value for the price. I guess you'll have to try it. The demo is good for a MONTH. No watermarks.

I completely understand your thinking, but the scripts approach does not seem to be a solid long-term solution. Adobe seem to have provided the Adobe Extensions route to enhancing their recent applications. This would avoid having to reboot twice in order to install / update your application, and give greater confidence that your application can be removed cleanly.

Only you can judge whether the expensive route provides a viable business model but, for my part, I cannot justify the cost, particularly when there are competing products available at a fraction of the cost.

[jcr6]

Andrew,

Here's an example about gamut that should illustrate my point.

Let's say that I've got a pixel with the following colors: Red = 200, Green = 100, Blue = 50.

If that pixel gets 25% lighter, we're still in gamut: Red = 250, Green = 125, Blue = 62.5 (depending upon the precision, I may or may not be able to represent the actual blue color).

If that pixel gets 30% lighter, we're out-of-gamut in 8- and 16-bit space: Red = 260, Green = 130, Blue = 65. We have no way of representing Red = 260, so Red gets clipped at 255. Now the proportions of Red:Green:Blue are wrong. The color has gone out-of-gamut.

However, in a 32-bit floating point space, there is not a limit at 255. The limit is 10^38, a very large number. Now, in Photoshop the usual number range of 0..255 is covered with 0.0 ... 1.0 (and is a linear space, not a perceptually uniform Gamma 2.2, like in 8- and 16-bit modes). But the ratio of Red:Green:Blue will remain the same for the same color whether the space is linear or not. So if I had a pixel that was Red = 0.8, Green = 0.4, Blue = 0.2 and I made it 30% lighter, I'd get Red = 1.04, Green = 0.52, Blue = 0.26. The Red isn't of gamut because the functional range in PSCS5 is about 2000. We haven't clipped. The color vector is preserved through various processing steps.

So gamut clipping does NOT happen in 32-bit floating point. And for that matter, highlights that are whiter-than-255-white don't get clipped either. That is the primary argument for this space.

Floating point does add more bits, to be sure (23 vs. 15 vs. 8), but it also adds a vast range. It's that added range without clipping that is the point.

[andrewrodney]

Let's say that I've got a pixel with the following colors: Red = 200, Green = 100, Blue = 50.

In what color space (which defines the gamut)? You seem to be missing the important point that R0/B0/G255 in ProPhoto is an entirely different color, has a different color gamut, falls within a different area of human perception (plotted on the CIE chromaticity diagram) than sRGB using the identical value!

If that pixel gets 30% lighter, we're out-of-gamut in 8- and 16-bit space:

No, it doesn’t. What makes you say that?

You really need to go study the vast differences between what encoding values and color gamut mean and differ. Color Gamut describes the range of colors. It defines where those color plot based on a color space against the only color space we humans need to have defined (human vision). Encoding values do not define gamut, it defines values of colors within a color gamut. More encoding values do not produce more or less gamut. A ProPhoto RGB doc and an sRGB doc in 24 bit color encoding HAVE THE SAME NUMBER of colors. The colors themselves are NOT the same. They fall within different areas of color gamut (based on human vision). There is no number for G255 in sRGB that lies in ProPhoto RGB at G255 because its not in that color space as defined by a set of numeric values.

Numbers alone don’t define a color! Numbers WITH an associated color space do. A color space is simply the plot of colors we can see based on experiments done before you and I were born when there was no such thing as computer encoding.

Ask ANY color scientist you can find, or any decent software engineer that writes code for dealing with color imaging if the encoding values affect color gamut. Cause the two are totally separate. The gamut of a ProPhoto RGB document is no different if its in 24 bit or 48 bit color.

You are missing a fundamental understanding of color gamut and encoding values used to define those colors. More bits, more color values, no more (or less) color gamut. Again, color gamut defines a range of colors. Bit depth defines the number of colors. More colors doesn’t equal more gamut.

Here’s a simple plot of two well know color spaces against the color gamut of human vision. They are differing sizes in gamut solely based on where their RGB primaries fall on this larger plot. It doesn’t matter what the encoding is (how many bits), the RGB values (the numbers you quote without the important info, the color space which defines what those colors look like to us humans), have no bearing on their positions on this plot. I don’t know how to make this any more simple for you.

http://digitaldog.net/files/sRGBvsProPhoto2d.jpg

[andrewrodney]

Even nvidia provides a 101 on encoding and gamut here:

http://www.nvidia.com/docs/IO/40049/...01_v02_new.pdf

Concepts of bit depth and color gamut while related should be looked as two separate items. Bit depth, the 30-bit part of “30-bit color” is a reference to how many bits of data are allocated for each color value in a pixel. Color Gamut refers to how much color a display or printer can give. It is possible to have a format with a high bit depth even though it is a low color gamut.

[jcr6]

Will you at least stipulate that at some point a color channel can get a value larger that 255?

SHEESH!

[jcr6]

And you're still talking about bits and I'm not.

Specifically a 32-bit number is FLOATING POINT.

The range that Adobe is using for normal images is 0.0 to 1.0.

I'm not talking about bits and precision (except that there is a lot). I'm saying that we can represent values larger than 255/1.0 in any/every channel and not lose those values.

Instead you're still trying to beat me up on the definition of "gamut".

No matter what the color space might be, if your channel value exceeds 255 (in 8- or 16-) it's TOAST.

[andrewrodney]

I didn’t beat you up, I’m correcting a statement you made that is factually incorrect:

Why 32-bit mode? A: Because out-of-gamut colors don't clip.

The bit depth has nothing to do with color gamut or gamut clipping period. Use the term color gamut correctly or don’t use it at all, that’s about the only beating I’d give you.

As the Chinese proverb says: The first step towards genius is calling things by their proper name.

[andrewrodney]

No matter what the color space might be, if your channel value exceeds 255 (in 8- or 16-) it's TOAST.

Numbers without an associated color space are totally ambiguous! That is the next idea you need to look at. R255/G0/B0 is not a color (color is a perceptual phenomena, not a numeric one). R255/G0/B0 in sRGB is a color based on human perception and we can easily plot and define that color. R255/G0/B0 in Adobe RGB is a different color (the numbers are the same, get it?). Typing out numbers without a color space is as ambiguous as me telling you I weigh 175. 175 pounds? Kilo’s? You can’t just spit out numbers for colors without a scale (that’s what a color space defines). Since you brought up gamut, color cannot be kept out of this discussion (otherwise stop talking about gamut clipping and color gamut).

I'm one of the authors of PercepTool. As you've observed above there are indeed three parts, and I'd like to outline them, what they're for, why they are separate, and the advantages of 16- and 32-bit modes respectively.

Your points about this product would be far better received if you stuck to commonly agreed and understood terminology with respect to color, encoding etc. I have no idea about HDR past the one book I’ve read, I have no dog in that fight. But if you come to a forum and talk about color gamut and encoding while representing your product, and do so by making statements like Why 32-bit mode? A: Because out-of-gamut colors don't clip, at least make your points technically correct. The term gamut and gamut clipping are well established terms in color management, something I know a bit about.