change default color-sets for view and radiation/sunlight hours analyses

[mostaphaRoudsari]

It is a good idea to have different gradient colors for different analysis types. We have two really good examples from Miguel (https://www.dropbox.com/s/eehp5ku6i4i1i89/sunlightHoursGradient.gh) and Jason (https://www.dropbox.com/s/atsayjjqqwp310o/viewGradient.gh).

@chriswmackey let me know your thoughts on this before I implement it. You also have created set of really good color gradients.

[arkdanielnielsen]

I think it is really good idea to give different simulations different color schemes. I do it with both own work as well as reports for clients to make it easier to read and understand. There could also be different color schemes for the honeybee simulations like mrcomfy's.

[mostaphaRoudsari]

@arkdanielnielsen agreed! Do you have color sets that you think we can use for different simulation types and what do you think about the ones that I linked above?

[chriswmackey]

The custom color schemes that I have come up with so far are the ones inside the shade benefit evaluator (red, white and blue) and the wind profile curve visualizer (light blue to dark blue). I was thinking that we might apply the same color scheme to the wind rose to allow for a consistent color scheme for wind data.

Also, I was thinking of color schemes for our eventual indoor temperature maps and I was thinking of a couple of options. Either the one in the Chicago Average Surface Temperature image at the bottom of this page: http://www.mackeyarchitecture.com/urban_cooling/index.html or the one that I used in the temperature change image of this interactive map: http://www.mackeyarchitecture.com/urban_cooling/map.html

If we plot indoor spatial PMV, I think that we should use the same color scheme as the shade benefit evaluator.

Mostapha, are you thinking that these color schemes will change the default colors of the 3D chart, or "color zones based on output" component depending on the connected data? I am thinking that it might just be better to leave these the default red, orange, yellow, blue scheme.

[mostaphaRoudsari]

Thanks Chris for your inputs. I'm thinking about standard simulations that we have and not the 3D Chart. I agree with you that it is just better to leave it as it is.

[arkdanielnielsen]

Maybe it is best to leave it as it is. It is almost iconic with the red, orange, yellow, blue - a trademark for Ladybug! Instead it could be showed in a example file how to differentiate different simulations !? Colors should reflect what it try to show, e.g. if it something with heat it should be warm colors, and the opposite with cold results. I like the below legend for wind (red=extreme/warning etc) (I also like to put icons to the scale/legend). Now when I look at it in this way it should maybe start with green color that could reflect something nice. Many colors have a inbuilt mood or emotion.

[mostaphaRoudsari]

Hi @arkdanielnielsen. Customization will always stay there as an option but I still think having different different default colors is helpful. PS: I love this legend. So story-telling. At some point I will hopefully have enough time to design some of these cool legends.

[mostaphaRoudsari]

Hi all, I changed the default color set to something similar to Chris's map. I borrowed the colors from color brewer color set. Here is an example (http://vega.github.io/vega-editor/index.html?spec=heatmap)

I personally think it is much better than the current color set and is still generic enough. As usual I'm open to disagreements and/or better suggestions.

@arkdanielnielsen @chriswmackey @stgeorges @ayezioro

via 81e045b6ba30243804bc8a10f16618f935642d3a

[ayezioro]

Hi Mostapha, This is a move from nice to nicer :-) Like the colors. Also like the Daniel's legend. -A.

[chriswmackey]

@mostaphaRoudsari and all,

I can agree that the new color scheme looks more sophisticated and polished than the previous one, particularly when it is used for temperature data and for highlighting hot/cold extremes that deviate from a median comfort.

However, I am also realizing that the new color scheme's lower saturation and greater emphasis on dark/light differences does not seem to be doing quite as good a job at highlighting the subtle differences that exist across the mean of a data set, which is something that I really appreciated about the older default. The new one seems to be a bit more focused on highlighting extremes in relation to a middle region, as evidenced by the fact that the summer months of the new chart are clearer than the old one but, in the Spring, the older chart seems to show more variation.

By relying on spectral differences in high-saturated color rather than dark/light differences, the older scheme seemed less biased towards the extremes or a particular part of the data set. This was nice to see before deciding which parts of the data that I wanted to emphasize with a custom color scheme through legend parameters. In this way, I liked that the old scheme was less focused on producing something 'polished' for thermal display and more focused on giving a view of the data that was not biased towards a particular part of the data set.

There are also a lot of particular cases where the new color scheme does not seem to be performing as well. Notably, I am not sure that I like how it looks with the psych chart and with data sets that are not about temperature or radiation:

Lastly, I really don't like what happens when you use it to display a data set that has only True/False values. I know that we don't have too many of these data sets in Ladybug but, when they come up, it is usually important to just seem them quickly and clearly. For example, when I plug in the comfortableOrNot output of a comfort component into the colored chart with the new color scheme, it is barely readable since both the blue and the red are very dark and very close to purple:

I also do not like that the red in the scheme is really close to the GH default red color for geometry.

Finally, I will admit that I am probably also just having withdrawal from the previous color scheme but there may be some merit in this as an argument for others too. The older color scheme has been really fundamental to my associations with Ladybug, all of the way from the colors used for the Ladybug logo to the Ladybug icon component colors. It has become a bit of an identity marker for the project and, to change this default color scheme seems like we are re-branding the whole project.

In summary, I would much rather have the original color scheme back as a default. If people really like this new scheme for certain types of data, I would be happy to implement it as a default specifically for those cases, which seemed to be the original reason for opening this issue.

Let's hear everyone else's thoughts. -Chris

[ayezioro]

I have to admit that my comment was based ONLY in the picture Mostapha uploaded. My bad not checking before responding. I fully agree with Chris's comments. The benefit seems to be lower than the "damage".

I've been seeing, and collecting, different color schemes along the discussions in the forum. Sometimes i use them when i want to show things differently. This can be a way to deal with this issue (having a library of color schemes)? -A.

[arkdanielnielsen]

Hi guys, Nice to have a discussion ones a while ;) I like the suggested color scheme, but... as I also wrote last year, I would suggest to leave it as it is. As Chris also writes, it is like a trademark for Ladybug. /daniel

[chriswmackey]

Ok. I think we should go through the aspects of this issue that we seem to agree on most to those we might have to build more of a consensus:

1) First, it seems that all of us unanimously would like a quick means of accessing a number of gradients that all of us use a lot. I have added a new library of common gradients in LB_LB along with a new component that allows you to quickly access all of them. You can see an example GH file for how to use the component here: https://app.box.com/s/n11do3yte44hdo82myfaj44pamte0agn

I have also put up a graphic online with all of the possible gradients that you can choose: https://github.com/mostaphaRoudsari/ladybug/blob/master/resources/gradients.jpg

I tried to include every gradient that I have ever seen used with LB but let me know if I am forgetting some important ones.

1. It seems that most of us agree that it would be good to have the old default color scheme back but we should definitely get Mostapha's thoughts before changing it back. The change in the default has created some bugs in the colors of my thermal maps so I will change it back to the old colors if we don't hear from Mostapha shortly.
2. To finally address the question in the title of the issue, I am going to outline the cases where I have already changed the default colors in my own components and then make a proposal for a few others. To outline the cases where we already over-ride the default LB colors, they are as follows: 1) Shade Benefit Evaluator

2) Thermal Comfort Percent / Thermal Autonomy

3) PMV / Degrees from Comfort

4) OverHeated Hours

5) UnderHeated Hours

Here are the new cases that I am proposing: 1) View Analysis

2) Shadow Studies / Sunlight Hours

Other possible cases that I think might be worth discussing but will not implement in this issue: 1) Illuminance 2) Luminance 3) Daylight Autonomy (These would all require some special reader of daylight results and so I think the decision is mostly in Mostapha's realm).

If we agree on the colors for view analysis and shadow studies, I can implement them very soon. Please let me know your thoughts. -Chris

[ayezioro]

This is so nice Chris!! As i said before i collected some color schemes. Here is a link with those patterns and instead a slider with the options i put a list from you can pick according to the scheme's name (just for user's convenience)., Between the color schemes i like the Ecotect's. I don't remember from whom i took them (my bad). I think it is Theodore, but ... can be someone else. The link: https://www.dropbox.com/s/bs6f72amsbbn0bp/19_UsingTheColorLibrary_AY.gh?dl=0 -A.

[ayezioro]

Forgot to say: Your examples are so great!!

[chriswmackey]

@ayezioro ,

I have taken into account the color schemes in the GH file that you sent. They are as follows:

1) It is good to know that the colors in the sunlight hours file mostapha uploaded from Miguel came from ecotect. I have since changed the name from 'Sunlight hours 2' to 'Ecotect' and I have replaced the original colors with the slightly more refined version in your file.

2) The black to white one was practically the same as the one I implemented and so I have not added anything here.

3) The blue to white is essentially the same as the 'shade benefit' scheme (originally 'Cold Hours 2') and so I have not changed anything here.

4) The two red/white/blue shcemes there are really close to the two that I have implemented (Thermal Comfort Colors and Shade Benefit / Harm) and I think that these two color sets are a bit nicer as they are informed by color brewer. If you can make a good case for why either of those two in you file is really different, I can include them in the library.

5) I have added the blue-to-yellow to the library under the name 'Blue to Yellow'. Let me know if you want it in there under a different name.

Updated example file can be found here: https://app.box.com/s/n11do3yte44hdo82myfaj44pamte0agn

-Chris

[ayezioro]

Perfect!! -A.

[chriswmackey]

Hello All,

I am heading out for a trip tomorrow and would like to clear up the issue as far as my edits are concerned. To address the bug that was created in the thermal map colors, I got temporary permission from Mostapha to put back the old default. If anyone has any major objections to the default color schemes I proposed for the sunlight hours/shadow studies or view analysis, please post in the next few hours. Otherwise, I will implement them them tonight (we can always revert the changes if someone misses this post).

-Chris

[ayezioro]

Have a nice trip Chris. Fine with me your suggestions. -A.

[arkdanielnielsen]

Nice components @chriswmackey ! I only had some thoughts/comments to sunlight hours where I use colors instead of black-white gradient. But then it is great that it is so easy to make your own gradient. Overall I think it is some good choices!

[chriswmackey]

@ayezioro and @arkdanielnielsen , Thank you for your input. I have changed the default colors for the view and shadow studies so I am going to close out the issue. If anyone has any objections, uncertainties, or other color schemes they want added to the library, please feel to re-open the issue. -Chris

[mostaphaRoudsari]

Thanks @chriswmackey and everyone! All I needed to do was to start this discussion again. Well done. :)

[claudioarchi]

Hello Guys

First of hall I think that having a quick aces to different gradients is a great idea. This being said if you have too many choices it will be the same as having none. So in my opinion 50% of the proposed gradients by Chris will be fine

Now regarding the view and view analysis and shadow studies it works fine to me.

Thank you all for your great work

Claudio Nunez Architecte Sent from Surface

From: Chris Mackey Sent: ‎Friday‎, ‎July‎ ‎17‎, ‎2015 ‎6‎:‎05‎ ‎PM To: mostaphaRoudsari/ladybug

Ok. I think we should go through the aspects of this issue that we seem to agree on most to those we might have to build more of a consensus:

1) First, it seems that all of us unanimously would like a quick means of accessing a number of gradients that all of us use a lot. I have added a new library of common gradients in LB_LB along with a new component that allows you to quickly access all of them. You can see an example GH file for how to use the component here: https://app.box.com/s/n11do3yte44hdo82myfaj44pamte0agn

I have also put up a graphic online with all of the possible gradients that you can choose: https://github.com/mostaphaRoudsari/ladybug/blob/master/resources/gradients.jpg

I tried to include every gradient that I have ever seen used with LB but let me know if I am forgetting some important ones.

It seems that most of us agree that it would be good to have the old default color scheme back but we should definitely get Mostapha's thoughts before changing it back. The change in the default has created some bugs in the colors of my thermal maps so I will change it back to the old colors if we don't hear from Mostapha shortly.

To finally address the question in the title of the issue, I am going to outline the cases where I have already changed the default colors in my own components and then make a proposal for a few others. To outline the cases where we already over-ride the default LB colors, they are as follows: 1) Shade Benefit Evaluator shadebenefitcolorshceme

2) Thermal Comfort Percent / Thermal Autonomy tcpimage

3) PMV / Degrees from Comfort degreesfromtarget

4) OverHeated Hours overheatedhrs

5) UnderHeated Hours underheatedhrs

Here are the new cases that I am proposing: 1) View Analysis viewanalysis

2) Shadow Studies / Sunlight Hours singlehour overaaday

Other possible cases that I think might be worth discussing but will not implement in this issue: 1) Illuminance 2) Luminance 3) Daylight Autonomy (These would all require some special reader of daylight results and so I think the decision is mostly in Mostapha's realm).

If we agree on the colors for view analysis and shadow studies, I can implement them very soon. Please let me know your thoughts. -Chris

— Reply to this email directly or view it on GitHub.

[ayezioro]

Hi Claudio, Your comment reminds me a good joke, where the bottom line of it is: "You don't cut options". If you guys insist i can try to write the full joke (The Pope is a main actor in the joke, so you can imagine where it goes :-) ). But saying that, i think than once you have the option ,you don't want to cut them. In this case, specially, when you have good defaults for the analysis, so you don't even don't have to deal with the gradient component. Only if you want more control. So i don't recommend to reduce the options. -A.

[claudioarchi]

Yeah I guess you are right. I took a look at Crhis file and its great. So I retract my self. I think having a good set of gradients is a helpful thing

Cheers all and keep the good work

[chriswmackey]

Thank you, everyone, for the comments and I am glad to see that the consensus seems to have held. @claudioarchi , I would agree with decreasing gradients if the list ever got to a size that seemed difficult to navigate with a drop-down list (I imagine somewhere around 40 gradients). For the time being (with 20 gradients, most of which have names that can be tied to other components in LB), I think we are safe. -Chris