Most important project for version 8

[Charles2]

It is great to work with version 7. The larger dialog fonts and drag-and-drop onto the PWP shortcut make the program even more fun to use. The new Watercolor transform continues to fascinate me. (It also makes me wonder whether display monitors will ever overcome the separate-pixel paradigm; one of the joys of prints is that inkjet drops mix slightly, yielding a smooth continuity.)

My vote on the most important thing for version 8 is to add the LAB color space to Color Curves,
to Mask | Color if that makes sense, and perhaps to Levels.

Some folks are LAB space fanatics; I am not one of them. I use simple but often hugely effective LAB curves. The Lab-L curve changes luminance with a different (non)effect on color than HSV-V. The Lab-a and -b curves bring out colors in ways that I have not figured out how to duplicate on the HSV-S curve nor with ColorCurves | RGB.

Today's personal computers handle LAB computations without noticeable delay.

And a minor suggestion: Color Remap could show the affected area on the image just like Selective Color Correction does.

[jsachs]

It would not be difficult to add Lab to Color Curves and perhaps to other transformations as well. The Lab color space is important for colorimetry as it mimics the sensitivity of the human eye to the apparent brightness of different colors. The one huge problem with editing in the Lab color space is that large sections of the Lab color space are unrealizable (i.e. they correspond to RGB values < 0% or greater than 100%), so it is really easy to clip one or more channels, especially the blue channel. This problem does not occur with HSV or HSL. Also, adjusting hue and saturation in terms of the a and b coordinates is not particularly intuitive. I do take your point however about being able to duplicate Lab adjustments used with other programs.

[tomczak]

Would introducing Y'CbCr, perhaps behind the scenes, be a viable option too? The reason is chroma noise reduction: I can't be sure, but looks to me that AS and Precision Gaussian could benefit by blurring CbCr rather than HSV-HS. Would that be useful, or are there reasons that that wouldn't be such a good idea?

http://www.dl-c.com/board/viewtopic.php ... t=10#p2757

[HanSch]

@Maciej:

Looking at your posts you seem to struggle with chroma noise reduction. And you appear to be not satisfied with your results in PWP. Of course it is most convenient to use a single application for all editing tasks, and we all agree that PWP has an impressive toolkit, but you could try an application like Neat Image, which is designed for noise reduction only. The stand-alone Home Edition has many settings, so you can tune to your needs.
I prefer the PWP raw-conversion over many others, including the one that came with the camera. For high ISO images I sometimes use little noise reduction in PWP raw-conversion, followed by Neat Image noise reduction just before sharpening (because the Home Edition doesn't save 48bit images). Chroma noise and luminance noise can be treated separately and I like the results.
But your demands/taste can be different, of course.

[tomczak]

Thanks! I use NeatImage occasionally (I bought Pro version a few years ago), and I think it's quite inspired and impressive application - after exchanging emails with Vlad, the programmer, I think I almost understand how it works and how to get what I want without obliterating the image. But it's more work, and no masks (well, one can composite it after in PWP), and often a simpler procedure could do just as well.

Chroma noise reduction is one of few things that is not that easily done in PWP as yet, and to me, along with sharpening halos control, it is one of the two ubiquitous procedures that make or break an otherwise good image. The need for both of them keep coming up all the time.

I keep driving at it mostly because of my naive belief that implementing the two would not require revolutionary changes, and the photographic benefits, including automation, could be great and generic. The infrastructure seems to already be there, for example AS (and the new precision Guassian) already does chroma blurring (but on HSV-HS, not Y'CbCr, I suspect, which erodes luminance too).

Similarly in sharpening halos department, AS can already control lower roughness threshold (but not the upper one). I've also seen USM implementation with separate amount controls for black and white overshoots. There were several discussions on halos in the past.

But this is all speculation - only Kiril and Jonathan know if this makes any sense and/or if it's worth it or possible to implement. But if it is possible at all, I think it would be sweet...

[JML]

LAB can be expressed in polar coordinates as LCH (Lightness, Chroma, Hue) akin to HSV. This helps with the non-intuitiveness of the Cartesian coordinates, specifically the a* and b* axis. This would be a nice enhancement for PWP.

[tomczak]

I'm confused a bit: wouldn't LCH representation of colours in Lab (btw: how does it relate to Luv?) space suffer from large areas of imaginary colours too? Would Y'CbCr, as used in JPG, meaningfully separate perceptual chroma from luminance just as well, but afford simpler and less clipping-prone reversible transformation back and forth from RGB/HSL/HSV?

NeatImage, mentioned before, seems to operate on Y'CbCr and this makes a difference in being able to separate chroma noise for instance, without chipping off luminance. CbCr may not be intuitive for colour corrections, which is how this thread started in the first place... Is there an optimal solution?

[jsachs]

Having played over the years with doing various transformations in different color spaces, I do not expect there to be much of a visible difference by doing chroma blurring or any other operation in Lab or Y'CbCr vs HSL as they are quite similar overall. The big problem with chroma noise is that is tends to have both low and high frequency components and it is hard to get rid of the low frequency part.

[tomczak]

Could dual threshold in AS/NS tab, similar to the freely movable soft threshold sliders in Mask/Color Range, applied to colour channels in either Y'CbCr or HSL (but not HSV) provide enough control to do the trick of removing both high and low frequency chroma noise?

[jsachs]

Low frequency noise requires a vary large blur radius to smooth out - otherwise the result is "lumpy". Using a very large radius is not so good at boundaries between regions of different color however. Thus some kind of ad hoc segmentation of the image into relatively uniform regions that can be heavily chroma blurred would seem to be required, but this is complicated. Why most digital camera chroma noise is like this I do not know, but I have seen patents describing the phenomenon and suggesting some ways to get around it.