_ColorConvertRGBtoHSL incorrectly normalised to 240

[QED]

At the end of the UDF, HSL values are multiplied by 240 for no reason.

	$avArray[0] = $nH * $_COLORCONSTANTS_HSLMAX
	$avArray[1] = $nS * $_COLORCONSTANTS_HSLMAX
	$avArray[2] = $nL * $_COLORCONSTANTS_HSLMAX

where

Global Const $_COLORCONSTANTS_HSLMAX = 240

There is no documentaion in the help file other than an external link. According to that link, there is no normalisation to 240. Also Wiki does not show any normalisation to 240.

In the converse funtion _ColorConvertHSLtoRGB, the input HSL values have all been divided by 240 (incorrectly assuming input is normalised to 240).

[Valik]

What makes you think it's wrong? Because it's not. Go open MSPaint and try to type 300 into any of the Hue, Saturation or Luminance fields of the color picker and see what it does.

[QED]

I originally wrote a reply to this. Took a lot of time. Was all wasted because we can't post replies to closed bugs? Would be good to be informed of this before the user wastes their time. Would also be good if you consulted the user as well before making conclusions based your flawed research.

Did you check other references - Help, Wiki, Photoshop, GIMP, HSL theory which has been around long before MS Paint? What makes you think they are wrong? Because they are not.

---

Valik Edit: Below is the original post copied from the logs

---

And what happens when you type 300 in GIMP (open source alternative to Photoshop)?
H range [0,360] (angle) and S&L range [0,100] (percent).

I don't have Photoshop but my cursory googling showed that Photoshop operates in exactly the same way.

The help documentation for _ColorConvertRGBtoHSL states:

var_R = ( R / 255 )                     //RGB from 0 to 255
var_G = ( G / 255 )
var_B = ( B / 255 )

var_Min = min( var_R, var_G, var_B )    //Min. value of RGB
var_Max = max( var_R, var_G, var_B )    //Max. value of RGB
del_Max = var_Max - var_Min             //Delta RGB value

L = ( var_Max + var_Min ) / 2

if ( del_Max == 0 )                     //This is a gray, no chroma...
{
   H = 0                                //HSL results from 0 to 1
   S = 0
}
else                                    //Chromatic data...
{
   if ( L < 0.5 ) S = del_Max / ( var_Max + var_Min )
   else           S = del_Max / ( 2 - var_Max - var_Min )

   del_R = ( ( ( var_Max - var_R ) / 6 ) + ( del_Max / 2 ) ) / del_Max
   del_G = ( ( ( var_Max - var_G ) / 6 ) + ( del_Max / 2 ) ) / del_Max
   del_B = ( ( ( var_Max - var_B ) / 6 ) + ( del_Max / 2 ) ) / del_Max

   if      ( var_R == var_Max ) H = del_B - del_G
   else if ( var_G == var_Max ) H = ( 1 / 3 ) + del_R - del_B
   else if ( var_B == var_Max ) H = ( 2 / 3 ) + del_G - del_R

   if ( H < 0 ) ; H += 1
   if ( H > 1 ) ; H -= 1
}

Note "HSL results from 0 to 1" and the absence of normalising to “MS Paint color picker”. So the function does not conform to it's own specification. I'm quite sure that's called a bug.

The standard according to Wiki and it's references is:
H range [0,360]
S&L range [0,1]
"Why do you think these references are wrong? Because they are not."

If this "standard" UDF is targeted at just MS Paint users then it should be labelled as such. For the average person who knows HSL theory (but never used Paint) this function is useless. They have to debug it first to work out why they are getting results not consistent with any documentation or industry standard.

If, for some reason, normalising to 240 is some obscure programming requirement in windows (changing background or whatever), then those people should know they have to normalise and they can adjust manually.

I'm reopening this because I don't think you or anyone else would seriously believe MS Paint color picker is (or should be) THE worldwide standard for HSL.

[Valik]

FYI: You just replied to a closed ticket, quite obviously.

Anyway, I just read your reply (I do not know why it was rejected) and all I have to say is what an arrogant prick you are to think you can re-open a ticket. It's people like you who think they know everything and wish to argue with us about our language and fight us by re-opening tickets that prompted us to disable the ability to open tickets in the first place. This is our language and our issue tracker and if we want to close a ticket, well, fuck you because it's not your place to tell us what we should or should not do with our language.

With that out of the way, let's move on. I don't know why you are arguing such a stupid thing. It's perfectly clear and you know this based on your other post that HSL values are typically represented in a couple different ways. I use either floats in the range 0.0 - 1.0 or a slight variation where the Hue is an integer in the range 0 - 360. Why the author chose to write to something else doesn't really interest me. It is what it is and just because it doesn't get your jollies off doesn't mean it's wrong.

And yeah, I've checked other references. Like the C++ code I wrote to convert from HSL in the two aforementioned representations to RGB. I saw the code was different so I tested with the easiest program I had available. It gave the same results as MSPaint which says to me the user wrote the code to do conversions for MSPaint (and all programs using the standard Windows color picker). Fine with me.

So what is your fundamental argument? That it doesn't work... or that it doesn't give the output you want? From what I can tell your whole issue is the latter because the function certainly works as advertised. If you want to argue the output is "wrong" then I'll just point you to my above statement where I already mentioned two different variations on the format I have personally used and ask you what makes you so special that you get to determine which format we use? Notice I didn't mention expressing HSL as degrees and percents - because I didn't use that representation in my C++ code. But all the methods are valid representations.

[anonymous]

I have at no time been rude or disrespectful to you, I would expect the same courtesy (did you not like your own words thrown back at you?). What gives you the right to speak to people like this? I'm sure you would be in violation of your own forum rules. Should we put it to the test?

The reopen function is available to me as a user and I clicked it. Why do you make it available otherwise? If someone spoke to you like that for using features given to you and you were trying to help improve the program, what would you think of “YOU” and “YOUR” language? Your hubris and bullying is quite disturbing.

Anyway on with the science. So my "fundamental arguments" are:

1. The function does not conform to it’s own specification in the help file. The function does NOT "work as advertised".

2. Wiki and all it’s references say that H range [0,360] and S&L range [0,1].

3. GIMP & Photoshop work as described above. H is in degrees and S&L in percent. You, yourself use this same standard. "What makes me special..."? Ask yourself, you're the one who doesn't use the function as written.

4. If this "standard" UDF is targeted at just MS Paint users then it should be labelled as such. For the average person who knows HSL theory (but never used Paint) this function is useless. They have to debug it first to work out why they are getting results not consistent with any documentation or industry standard.

5. If, for some reason, normalising to 240 is some obscure programming requirement in windows (changing background or whatever), then those people should know they have to normalise and they can adjust manually.

6. Given all the above information, I don’t think that you or anyone else seriously believes that MS Paint color picker is (or should be) THE worldwide standard for HSL.

7. QUOTE

“If you want to argue the output is "wrong" then I'll just point you to my above statement where I already mentioned two different variations on the format I have personally used and ask you what makes you so special that you get to determine which format we use?”

a) Please provide the reference for the MS Paint method along with your objective arguments for using it as a STANDARD.

b) Please define “we” as in… How many people serious about color use Paint? If by “we” you mean “us programmers” then the function does not belong under “color” it belongs somewhere else where people actually care that windows works in 240.

8. QUOTE “But all the methods are valid representations [of C++ code].”

We are not talking about programming. We are talking about a scientific principal relating to color. It’s still the same principal no matter if you coded it in C++, Excel or with pen and paper.

Having made your conclusions (that are not supported by science) your ego has left you no option but to continue making your case that "you are right and I am wrong". I appreciate that you probably have vast knowledge when it comes to programming and I also appreciate that you are not expected to be an expert in everything that we might use computers for.

So bottom line is your ego will probably prevent you from reversing your decision and you'll probably think of some internally consistent way of justifying why you too do not use the function as written.

As I pre-empted this outcome (based on your predictable attitude) I will probably release my own version of the UDF. It will be interesting to see the extent that you try to censure me. Maybe then the whole community can have an informed discussion about the science (as opposed to this bizarre defence of MS Paint).

In closing you would be well advised to re-read what you've written - it's quite ugly isn't it? I bet you'd be proud to show a future employer your achievements here - perhaps new users or companies thinking of using AutoIt? The messages they should take from this are:

1. Do not use features provided to you for fear of bullying and intimidation.
2. Those features will be taken away if used as intended.
3. Valik claims to be a part owner of the language.
4. It is the developer’s absolute right to behave appallingly in contravention of his own forum rules. Intelligent adults are expected to accept this behaviour “or leave”.
5. Discussing legitimate scientific inaccuracies is “stupid” and grounds for being verbally abused.
6. The apparent bug is invalid if it works in the one (obscure) program the developer uses.
7. The fact that the software does not conform to its own written specification is not a bug.
8. All scientific literature and industry standards will be ignored at the discretion of the developer if it “doesn’t interest him”.

_
Endnote: I notice you found my “missing” post. This post was written while that post was thought missing, hence the repetition.

Interestingly this post also went "missing" after I saw it published on the page, lucky I had a backup.

[Valik]

Replying to anonymous:

I have at no time been rude or disrespectful to you, I would expect the same courtesy (did you not like your own words thrown back at you?).

You haven't? As I said, you're a dick for thinking you have any say what-so-ever in re-opening our tickets. I honestly don't know why the reopen radio is showing up but it's not supposed to. As I said previously, it's people like you who can't even be arsed to read WikiStart that prevent us from letting users have that privilege. See the part of WikiStart where it says don't bloody argue on Trac, take it to the forum.

So yeah, you're being quite rude, not even following our own rules about arguing here.

What gives you the right to speak to people like this? I'm sure you would be in violation of your own forum rules. Should we put it to the test?

What gives you the right to determine what is and is not rude? Maybe I consider your incessant nagging rude? Did that ever occur to you Mr. High and Mighty?

Your hubris and bullying is quite disturbing.

Your refusal to comprehend my posts is also quite disturbing.

Anyway on with the science. So my "fundamental arguments" are:

1. The function does not conform to it’s own specification in the help file. The function does NOT "work as advertised".

You don't know what specification it's supposed to conform to. You've found an errant comment in the file and are trying to treat it as a specification. Here's a clue: Comments are sometimes irrelevant. I can't tell you the number of comments I've seen that don't pertain to the surrounding code because the code was changed and the comment was not. Get over it, it proves nothing other than your argument is so weak that you're grasping at straws.

2. Wiki and all it’s references say that H range [0,360] and S&L range [0,1].

3. GIMP & Photoshop work as described above. H is in degrees and S&L in percent. You, yourself use this same standard. "What makes me special..."? Ask yourself, you're the one who doesn't use the function as written.

I don't use the function at all so I don't really give a shit at all. And FYI, your comment about my usage should have fallen in #2 since I don't use percentages, I use decimal numbers (yeah yeah, just a * 100 away from being a percent).

4. If this "standard" UDF is targeted at just MS Paint users then it should be labelled as such. For the average person who knows HSL theory (but never used Paint) this function is useless. They have to debug it first to work out why they are getting results not consistent with any documentation or industry standard.

Your quotation of the word "standard" implies you don't understand what it really means in this context. It means they are standard AutoIt functions, not that they conform to some external standards body.

6. Given all the above information, I don’t think that you or anyone else seriously believes that MS Paint color picker is (or should be) THE worldwide standard for HSL.

I don't see anyone claiming it is or should be the worldwide standard. Hyperbole FTL.

We are not talking about programming. We are talking about a scientific principal relating to color. It’s still the same principal no matter if you coded it in C++, Excel or with pen and paper.

We are talking about programming because your whiny hissy bitch-fit centers around the fact that the colors aren't represented how you want. You're clearly missing the point where programming choices about accepted input and output are related to the specific programming implementation and despite what you seem to think it's not a requirement by "god" or anyone else that this conform to any industry standard.

Having made your conclusions (that are not supported by science)

I never claimed science supported anything.

your ego has left you no option but to continue making your case that "you are right and I am wrong".

Oh, you mean what you are doing? With all your refusals to accept that you're just flat out wrong with every basic assumption you've made about the function? You are wrong in that it conforms to any standard and you are wrong in your assumption that it should conform to any standard. You are wrong in thinking anyone gives a shit about your "HSL theory" bullshit because chances are anybody else that cares will write their own damned function to work with whatever ranges they want instead of bitching their stupid ass off about how because they use standards they are cool or some other bullshit. Take your damned HSL standards and shove them up your ass. This function doesn't conform to them, it was never intended to conform to them as judged by the output and behavior so get over it and move the fuck along. Otherwise I'm taking the functions out of the language entirely. Is that what you want? For the functionality to be removed from users who like it because one whiny little know-it-all bitch can't accept that maybe the world doesn't revolve around them?

So bottom line is your ego will probably prevent you from reversing your decision and you'll probably think of some internally consistent way of justifying why you too do not use the function as written.

I don't use the function as written because I don't need it. Shocking, I know. As for my ego? I think it's perfectly clear who's ego is bigger here. Here's a hint: I'm a custodian of the evolution of this language, not some puppet to be pulled around by arrogant dickwads who make incorrect assumptions and then argue until they are blue in the face about it.

As I pre-empted this outcome (based on your predictable attitude) I will probably release my own version of the UDF. It will be interesting to see the extent that you try to censure me. Maybe then the whole community can have an informed discussion about the science (as opposed to this bizarre defence of MS Paint).

I may remove you for your attitude and your comments, not because of your code. As long as it falls within the reasonable bounds we've set for unacceptable content I don't give two shits what you post (nor about you for that matter).

In closing you would be well advised to re-read what you've written - it's quite ugly isn't it? I bet you'd be proud to show a future employer your achievements here - perhaps new users or companies thinking of using AutoIt? The messages they should take from this are:

Oh goody. Now you're really shoving your foot down your throat. This will be fun to shred.

1. Do not use features provided to you for fear of bullying and intimidation.

Wrong. It's more like, "Do not bitch about features unless you are 100% sure of the intent behind them. You are clearly not sure of the intent behind the functions in question so you've raised a bitch fit over them for no reason.

2. Those features will be taken away if used as intended.

No, those features will be taken away if people incessantly bitch about them.

3. Valik claims to be a part owner of the language.

Where exactly has this been stated or implied? Or is this another one of the moronic conclusions you've jumped to? I have not nor have I ever claimed to be any portion of owner of the language.

4. It is the developer’s absolute right to behave appallingly in contravention of his own forum rules. Intelligent adults are expected to accept this behaviour “or leave”.

No, intelligent adults are expected to understand what the fuck they're talking about before they go on long rants. Those who miss the point are usually taken to task for it.

5. Discussing legitimate scientific inaccuracies is “stupid” and grounds for being verbally abused.

Again, you miss the point. Your scientific reasoning is meaningless when it's not relevant to the intent of the function in question.

6. The apparent bug is invalid if it works in the one (obscure) program the developer uses.

Or basically any program that uses the Windows color picker. But anyway, in case you didn't notice, we accept contributions from the community. Somebody thought the function would be useful so they submitted it. I can't really justify the existence of the visa library in AutoIt because that seems even more niche than HSL but there it is. Should we change to a policy where we accept nothing? Would that make you happy?

7. The fact that the software does not conform to its own written specification is not a bug.

The only problem with this statement is that you don't know what specification the function is supposed to conform to. You're jumping to conclusions based on a comment in the source and perhaps a documentation link failing to realize that maybe the function changed and the other material is out-of-date.

8. All scientific literature and industry standards will be ignored at the discretion of the developer if it “doesn’t interest him”.

They are ignored when they are not relevant. Trying to make them relevant as an argument for why something that was never intended to work how you want should work how you want is not dismissal. It just means it's not relevant. Astounding.

Interestingly this post also went "missing" after I saw it published on the page, lucky I had a backup.

If you are attempting to make some implication that it was censored then you are wrong. I'd much rather take you to task in public than remove something. I only remove things like offensive images or links to things that shouldn't be linked to. I leave user stupidity and my responses to it for all to see.

Now, to wrap this up. It's time to play what I'm sure will be called a "power trip" card. This subject is closed. Further discussion on this will result in your removal from the site for awhile. My fundamental reason for doing this is:

1. You are clearly violating the issue tracker guidelines by inciting this argument here.
2. Your entire premise, your justifications and arguments are based around assumptions you have made that this function should be standard or conform to an industry standard. These assumptions are wrong. It's clear to me that the author's intent was to provide HSL functions for working with colors as represented in the standard Windows color picker dialog. No more, no less.
3. If you have issue with the functions you should have just said "the documentation should mentioned this is how these functions work". Nobody needs these long Wikipedia quotes explaining HSL beccause quite honestly the only person who cares is you.

[Valik]

It is now fixed so that Trac no longer misleadingly gives the impression you can re-open a ticket.