Tanel Posted March 27, 2008 Share Posted March 27, 2008 Hi, while building and testing a new plugin, I discovered that Hue/Saturation effect in PdN renders somewhat jagged results, especially noticable on smooth gradients. I know that this is caused by RGB>HSV>RGB conversion which is not 100% accurate. I studied the PdN 3.22 source and came to conclusion that accuracy falls mostly during color values being thrown between several operations (UnaryPixelOps, RgbColor, HsvColor, ColorBgra). Current effect system passes color values between color operations by (int) or (byte). Therefore precision is rounded down repeatedly, resulting with coarse results. I thought that this can be improved. "Bad" rounding can be avoided with passing color values by (float). To test my theory, I collected the pieces of PdN 3.22 source and put together Codelab code to imitate the color operations. I replaced the (int) or (byte) conversions with (float) where possible. Where converting to (byte) was inevitable, I used round() function before conversion. (Sidenote: I haven't analysed the impact of each change separately, so some of those may be useless.) Results are very good. Gradients are rendered smoothly even after running the effect several times. You can download the codelab source with few comments in it (.cs file) and improved effect (.dll file) here: -- attachment removed 2008-12-24 -- download the "Hue / Saturation+" as part of my plugin pack. To test it and compare with original effect I recommend this test image with color, saturation and brightness gradients. Here are some examples This is a piece of the linked testimage. See how gradients have got tiny steps in the middle pic. Even gray one which should not be affected by saturation adjustment. The right pic is still nicely smooth. Now a "real life subject": piece of sky from a photo. Sky is always smooth gradient in terms of color. I added contrast to exaggerate the result. See how middle pic became blotchy in some areas, while the right pic still holds up the gradient quite well. One more issue which I *think* is wrong with original Hue/Saturation effect: order of processing. Currently the adjustments order is Saturation>Hue>Lightness. I think this is wrong because in case of extremely saturated colors (R, G or B channel at 255) the Saturation adjustment itself will change hue *before* Hue adjustment takes over. Some of you may think what's the difference, but there *is* difference because Saturation adjustment handles different colors differently. Correct adjustments order would be Hue>Saturation>Lightness, so that Saturation adjustment reads the intensity() value from Hue-adjusted color. For example, take the above linked test image and open original Hue/Saturation effect. play with hue slider - color wheels "roll" smoothly. Now dial in saturation 150 and play with hue slider again. No more smooth rolling - color areas get stretched and compressed while you change hue. Now try the same with "Hue/Saturation IMPROVED" effect where I have changed the order. See the difference? I hope the improvements can be included to PdN somehow. Please, your comments! hue_saturation_improved.zip Quote Link to comment Share on other sites More sharing options...
Join the conversation
You can post now and register later. If you have an account, sign in now to post with your account.