Add some support for HUSL not LCHab or LCBuv (Hue like in HSL, Luminance like in CIE and chroma)

[ChameleonRed]

Here is what is grail of color for human subjective vision - it allow to choose color with same luminance.

http://www.boronine.com/husl/

I found also similar advanced color picker for cielab but without HUSL. http://www.virtuosoft.eu/code/bootstrap-colorpickersliders/ http://www.virtuosoft.eu/code/jquery-colorpickersliders/

It will be nice if I can create HUSL colors since it is human friendly approach. Consider such feature in colormath since it is leading edge. LCHab is not intuitive since hue is not linear with human perception as I feel.

[ChameleonRed]

I have finally found HUSL in python from creator of HUSL page - looks that I solve problem if tests will be successful. I share solution with you https://github.com/boronine/pyhusl - it is great thing simple balance artistics colors for designers. It will be nice if such thing will be in colormath.

Who search will find :)

[gtaylor]

It looks neat, but also appears to be somewhat underdeveloped. I don't even see any formulas listed outside of his reference implementations, which appear to be in varying states of readiness.

[ChameleonRed]

That is the right of being on leading edge - there will be no formulas - it need to be invented and developed - creation emerges from black hole. Algorithm is not the best but gives good results only for D65.

It is some kind on LCHab deformation giving in my opinion more intuitive colors than LCHab it self.

Idea is easy hue is like in HSL but lightness is replaces by luminance to keep same gray level for color - such hue is very natural for artists/designers.

[gtaylor]

Sure, I'm all for being cutting-edge, but ultimately the burden of maintenance falls on me. I don't think I'd feel comfortable having this in the codebase, given its current state of development/adoption. If it ever shakes out and gets a little more formalized, I'd definitely be interested. However, it looks like this thing is still evolving.

[ChameleonRed]

Some things are contradictory for example being for cutting edge and not accepting things evolving or not formalized by science world. I see clear such contradiction.

I think you can include experimental features without problem to be cutting edge like Google often do and deliver partially not working code sometimes like Dart or App Engine.

There is time for one more color library since all three which I tired to use is not good enough not because of HUSL but because many bugs and design holes or lack maintenance.

Colormath looks good but code quality is only good (unclear or complex patterns (conversion is too complex you can cut iterating tables and just specify conversion explicite like lab(xyz(rgb)) - simpler, lack of tuples a[1] is faster that a['dict index'], lack of optimization some precision problems). Can be cutting edge but will be not I think.

Colorpy is excellent in some places and buggy in others - efficient code and clear and stopped evolution :)

Husl completly ingores illumilant and will never consider this knowing author but I can be wrong :)

Thank for attention.

[gtaylor]

We can't be all things to everyone. python-colormath is almost a 100% straight transcription of the commonly used math formulas on Brucelindbloom.com, so in that regard it is clear and readable if you are familiar with said formulas. Code quality is so subjective that nobody will ever be entirely happy with something someone else wrote.

HUSL isn't ready yet. Sorry!

[ChameleonRed]

Sure, you can not be all thing to everyone- it is not matter. Being on cutting edge need some experiments.

I am impressed by your library and have good impression.

On other side still see hole in CIE Lab, HSL I can not hide this hole without HUSL - It will be nice if all things will be in one library and you will be open on contribution experimental code.

Each evaluation is subjective and all perception is subjective but I think you can improve you code style and become cutting edge programmer from top average - i can give you some suggestions:

• always make code simple and readable
• keep constants near code
• calculate constants with highest precision
• simplify conversion you do not need meta language compiler inside code simple is a(b(c())) that for i in [a, b, c] - it is little more code but it is very clear for debugging (avoid overoptimization or overautomation)
• add unit tests and learn test driven paradigm
• add some simple assertion you will kill the most serious errors
• use tuples/iterators rgb[1] is better than rgb.r tuple(rgb) than tuple(rgb.r, rgb.b, rgb.b) since simpler and more readable

Thanks for response have a nice day - I probably will path and push you will do with this code what you want or never publish.

[gtaylor]

python-colormath's purpose isn't to be on the cutting edge. This module is to provide reliable, accurate representations and conversions of popular color spaces. HUSL is not popular, and hasn't even settled on an implementation yet.

I'm glad you like HUSL, but no, just no. I don't want it right now. There's bleeding edge and then there's completely unstable and very seldom used/adopted. It's a bad fit for this module.

As for the other stuff, most of it was pretty vague and subjective, but I'll attempt to address the points

• Please be more specific about what you find not to be simple and readable by submitting specific issues you have. If I agree with you, I'll improve them. I may not always agree, though. I didn't agree with your pull request that introduced indirection and some poorly named functions.
• I disagree about keeping constants near code 100% of the time. You'll end up with circular imports if you have multiple sub modules using the constants (as we do). I'm entirely against deferred imports to get around that, as it can introduce nasty behavior.
• I tend to disagree that conversions should be done in the form of a(b(c())) because you are then complicating your Color constructors quite a bit. I don't find that to be Pythonic. As it stands right now, the conversion logic is neatly separated and entirely optional.
• We have pretty thorough test coverage. See the tests directory. I'm always open to additional tests in pull requests.
• With the assertions, same thing as the readability. Specific examples or pull requests would be considered. This statement is too general to be helpful, though.
• We have methods that return tuples. See the documentation.

[ChameleonRed]

HUSL is not popular as RGB some years ago and CIE Lab, Luv, LCHLab, LCHLub and XYZ today - to be specific - this argumentation is common sophism (looking valid argumentation basing on hidden logic fault which makes it invalid). BTW Android was not popular too :)

HSL is much more popular than RGB - web designers not use RGB at all some time use traditional HSL. First of all art compositions: triad, tetrad, complementary, analogic, compound, shades all is HSL (sometimes traditional).

Some examples to be specific:

1. The best designer: http://www.workwithcolor.com/hsl-color-picker-01.htm.
2. Again commercial (HSL is hidden in wheel - composition is HSL): https://kuler.adobe.com/create/color-wheel/
3. The other the best designer with Traditional HSL - see palette is deformed to use old tradional painters palette which gives much more rich colors - it is look like HSL but it is traditional HSL where hue deformed by perception - more oranges less greens: http://colorschemedesigner.com/

I do not want comment more you code or do more push I specified some general remarks you can use it. No time and I think it will be waste of my time since you will reject the most. I just comment this because I am impressed by your deed.

I am doing projects with 3+ persons and about 500k core lines, superoptimization, superscaling (Hadoop, threading), mass data, telco of web applications and more often leading them. I have good skills to design and eliminate problems.

At my impression you are now top average coder need little experience to jump to higher level - please do not be offended - I feel you have potential/skills to easily improve it. Shortly you can be the best after some years of training :)

• little too talkative interfaces (see tuples)
• invalid/too much separation (you generate too much files to hide some small data which should be near use) - CONSTANTS must be NEAR for sure - CONFIGURATION options must be FAR!
• average understand code execution performance and error avoiding (more code repetition more errors - more lines higher chance of error - less reading or more readable higher chance to detect errors - same is with assertion specifying them explicite keep checks when code becoming large)
• lazy loading is crucial in human/web/mobile/games application for sure - it is not important for scientist, engineer! - first what I do before library use I am checking loading time if it loads all and waste time and power I will reject use of iit - i.e. 1s overhead is bad design for sure - second I am checking memory overhead.

I found methods with tuples - but consider that tuple(rgb) is more natural for developer than tuple(rgb.generate_rgb_tuple()) (!too talkative).

My push was not bad - function is names very good https://github.com/gtaylor/python-colormath/pull/29/files :)

You can polish it as you want since it is private - better is add and improve than reject - more constructive :)

This is much better (shorter to read and check):

+    temp_x = __cie_lab_f(cobj.xyz_x / illum["X"])
 +    temp_y = __cie_lab_f(cobj.xyz_y / illum["Y"])
 +    temp_z = __cie_lab_f(cobj.xyz_z / illum["Z"])

Than:

-    if temp_y > color_constants.CIE_E:
 -        temp_y = math.pow(temp_y, (1.0 / 3.0))
 -    else:
 -        temp_y = (7.787 * temp_y) + (16.0 / 116.0)
 -   
 -    if temp_z > color_constants.CIE_E:
 -        temp_z = math.pow(temp_z, (1.0 / 3.0))
 -    else:
 -        temp_z = (7.787 * temp_z) + (16.0 / 116.0)

This is much faster (not care too much about CONSTANT names which is not public - must be unique any name is better than 16.0 / 116.0).

+__CIE_1_3 = 1.0 / 3.0
 +__CIE_1_3_29_6_POW_2 = 1.0 / 3.0 * math.pow(116.0 / 24.0, 2.0)
 +__CIE_4_29 = 16.0 / 116.0
 +__CIE_6_29_POW_3 = math.pow(24.0 / 116.0, 3.0)

+def __cie_lab_f(x):
 +    if x > __CIE_6_29_POW_3:
 +        return math.pow(x, __CIE_1_3)
 +    else:
 +        return (__CIE_1_3_29_6_POW_2 * x) + (__CIE_4_29)

Than:

-    if temp_y > color_constants.CIE_E:
 -        temp_y = math.pow(temp_y, (1.0 / 3.0))
 -    else:
 -        temp_y = (7.787 * temp_y) + (16.0 / 116.0)
 -   
 -    if temp_z > color_constants.CIE_E:
 -        temp_z = math.pow(temp_z, (1.0 / 3.0))
 -    else:
 -        temp_z = (7.787 * temp_z) + (16.0 / 116.0)

[ChameleonRed]

Try this book that is like true bible for master programmers - probably you have read it but I do not know - little heavy but you can read 10 page per week to complete in year with good understand.

Whatever it will not replace collecting experience in design, coding and testing.

http://www.amazon.com/Code-Complete-Practical-Handbook-Construction/dp/0735619670/ref=sr_1_1?ie=UTF8&qid=1400608635&sr=8-1&keywords=perfect+code

[gtaylor]

wow, Cezary, your tone is very condescending. I'm not looking for advice for how to transcend to the next level of programming acumen. I'm here to maintain and grow an accurate color math module.

I get that you are trying to help, but after reading all of this, I am going to give you some friendly advice of my own:

• You've got to learn how to accept it when someone says "No", and even provides an explanation for the decision. I don't think you fully grasp why things are done like they are in python-colormath, and that's OK. python-colormath is used in all sorts of different applications, some of which are very large, complex, and expensive. The needs of the userbase as a whole are far more important than any one individual.
• You can't get defensive and all passive aggressive when someone rejects your pull request. It's OK to discuss it, but if it becomes clear that the maintainer isn't going to bite, drop it.
• Nobody cares how good a programmer you think they are. I have never seen such an arrogant, un-solicited thing in an issue tracker as "At my impression you are now top average coder need little experience to jump to higher level".
• Talking up your experience/credentials is silly. This is an open source project, not a dick waving contest. I simply don't care what trophies you have on your wall. If you think that I do, you have a much higher value of self than is healthy. I don't want HUSL, and I didn't like your pull request. There's no agenda there. DealWithIt.gif.

So here's where we stand:

• HUSL will not be in python-colormath right now. Say it with me, "HUSL will not be in python-colormath right now." Leave it, we're done with this.
• If you have specific improvements in mind for the module, send a pull request. If it legitimately improves things, I'll accept it. Your first one was sub-par for the reasons listed in the PR. That's OK, no need to get defensive or try to argue repeatedly afterwards. Move on.
• Try not to be so condescending. This is open source, nobody wants or asked for your judgement. I have a hard time taking the rest of your responses seriously because of your tone.

[ChameleonRed]

My tone is "very condescending" but I think not much than other participants of this discussion :)

I was very specific as you asked and show you example of code where improvement can be done - it was same which I was improved - it can be others not matter to make example - same rule for all.

I said you that:

• I did not want to offend you by evaluation
  • you think that I want you offend.
• I praised you "At my impression you are now top average coder need little experience to jump to higher level" since it is not easy to be over average and average not mean bad
  • you told me that I am arrogant.
• I agreed with your rejection
  • you think that I want change your mind - it is impossible to change your mind since you express it directly.
• I would not ask you about change any more since simpler is fork or use other solution
  • you think that I am asking.

That is your misunderstand - I do not want develop or overdevelop - http://en.wikipedia.org/wiki/Straw_man thanks for discussion. I understand that you will not change mind now.

Sometimes humility is not understand as it is - nice movie about it: https://www.youtube.com/watch?v=jU9g8-a2xHo

There is nothing bad in learning, experience, skills, judgement, truth and I think you will agree inside and can disagree outside. Thank for remarks - I am often "so condescending" - since often people except it from project manager - I was not too much here.

I am much more easy going than "condescending" and I can not accept your rules of contributing since prefer create code than ask you about push.