ennixo

Hi Tanel, of course you can use it, everyone can use it. It's just a small free algorithm, not a super-duper-licensed-patented-code =)

Ok... I don't know if this will help Paint.Net, maybe can help someone... I've been able to write an algorithm with only integers and with accurate result. The trick is the scale of the values (H : 0..24480, S & L : 0..4080) wich gives enough precision to convert from RGB to HSL then back to RGB and to get the same RGB. It also uses a small lookup table to scale down RGB from 4080 to 255 with a round. I tested the performances, it is 2.4 times faster than the floating-point algorithm. Here it is ! OptimizedHSL.zip

After some research, I've been able to highlight such a "bad result" (but really better than PDN) in Photoshop. It means they probably developped extremly complicated algorithms based on integers. As such an algorithm is certainly by far too complicated to me, I think the good choice for PDN would be to keep using floats but without any rounding. Hue, saturation and lightness must be floats and remain floats to get modified until they turn back to RGB. For exemple, the Hue of RGB (85, 120, 201) is 221.8965. If you keep this exact value, you will get the exact RGB when you go back to RGB. If you round, ceil, floor or just cast this value, you won't be sure to get the exact value. So, the only thing you have to do is to keep HSL as floats and the result will be color perfect. I tried it with all possible values for RGB (RGB => HSL => RGB) and the result is always exactly the same.

Ok, I did it but there are some changes : 1. It doesn't use the HSV but the HSL algorithm. 2. The L component is not beautiful when modified (keeps the saturation, looks oversaturated). The solution is to leave the L component and then to apply the change directly on RGB when modifying Hue/Saturation/Lightness. 3. The quality is a little better than the actual algorithm but not that much. 4. I computed all possible values and compared to the good values, there is a maximum error of 1 when converting from RGB to HSL and 2 when converting from HSL to RGB. Average error vary between components from 0.05 to 0.5. 5. H component is scaled to 0..359, S and L are scaled to 0..255. I didn't benchmark this version but it may be about 3 times faster than the actual algorithm. Feel free to improve the code =) PdnHSL.zip

Nice improvement. A speed optimisation may also be done to this by using only integers with lookup tables (especialy for multiplications and divisions). For exemple, when you need to multiply 2 numbers [0..1] but you have 2 numbers [0..255] you call the LUT which returns the result. Those LUTs are 65Ko long but it is faster to do this than using doubles (or floats). The quality issue would just disappear because numbers are always scaled to [0..255] (and not [0..100] like the current algorithm). I developped such an algorithm and it is 3.2 times faster (rendered as fast as PS' algorithm, nearly instant). However, I'm experiencing some problems : - Increasing saturation slightly decrease light on some colors (and decreasing sat increase light on those colors) - Increasing value only affects colors which are not affected by the saturation issue. If I'm able to find the problem, I'll post my code, if someone wants to try to find the problem, just tell me, I'll post my code.