Mantis Bug Tracker

View Issue Details Jump to Notes ] Print ]
IDProjectCategoryView StatusDate SubmittedLast Update
0000316OLVUser Interfacepublic2011-10-18 14:432012-08-06 20:48
ReporterBenFenner 
Assigned ToFred 
PrioritynormalSeverityminorReproducibilityN/A
StatusclosedResolutionfixed 
PlatformAllOSAllOS VersionAll
Product Version0.0.1-SNAPSHOT 
Target Version0.0.3Fixed in Version0.0.3 
Summary0000316: Make default color selection better.
DescriptionMake default color selection better.

With major UI overhaul have the colors not chosen until absolutely needed. Compare colors already present on that track and pick a good contrasting color.
TagsNo tags attached.
Attached Files

- Relationships

-  Notes
User avatar (0000515)
Fred (administrator)
2011-11-02 08:48

Dirty use of the tracker, I know, but:


java.awt.Color is incompatible with expected argument type MarkedColor in org.diyefi.openlogviewer.coloring.InitialLineColoring.giveBackColor(Color) CORRECTNESS GC_UNRELATED_TYPES 89 High
java.awt.Color is incompatible with expected argument type MarkedColor in org.diyefi.openlogviewer.coloring.InitialLineColoring.giveBackColor(Color) CORRECTNESS GC_UNRELATED_TYPES 90 High

Check out "giveBackColor" which takes a Color and tries to compare it with MarkedColor objects. See the PMD report in mvn site:site for a reference and linked explanation. Even if this works, it's dirty and bad. Perhaps it's the cause of the grey fields?
User avatar (0000516)
BenFenner (developer)
2011-11-02 12:45

There are lots of ways to do this better. I was completely rusty when I did this stuff. It will get a complete overhaul when new UI stuff happens.
The problem seems to be my attempt at providing or overriding .equals() functionality.
User avatar (0000903)
Fred (administrator)
2011-12-04 23:29

This really does need to have some intelligence in it. If it were a single division, then a fixed list would be a goer, but if you have 6 divs and you put one in each, then one in the first again, the two in the first will naturally be close colour wise. If you have a fixed list and you use the same list for each div with repeats allowed it'll be ugly. If you try multiple lists you'll get weird overlaps.

Thus the algorithm that figures out the best colour needs to know something about contrast, and what is in the div this field is going into and what is in the others too.

IE, it needs to take the best contrast match with the current area while not coming too close to the other divs either and not taking colours up front for different divs that deplete the best colours for another div.

I guess what that means is that you need a base list, and then a tone applied based on number of divs and initial fields chosen to be not the same base as the other divs existing fields. that way you end up choosing pure blue for the first one in the first div, off red for the first one in the second div, differently off green for the first one in the third div, and so on. Then the pure green and red are still available for the first div.

Or perhaps there are enough colours with a single list and no caring about divisions considering the likely trace count 5 - 10 normal and 20 odd max.

End pondering.
User avatar (0000952)
BenFenner (developer)
2011-12-10 15:22

Tell me something I don't know Fred. ;-)

No need to make the colors aware of the other divisions if we allow a trace to change color when it goes to a different division and/or be in more than one division at once with different colors. The key/legend will show you what you're dealing with.
User avatar (0000953)
Fred (administrator)
2011-12-10 15:34

I think that there is a need to have them be aware of other divisions. I want to be able to say "the bright green one" and not have to say "in the 5th division" as well. I guess a single list with ever closening colours is probably the best thing.

RGBCMYHHHHHHMMMMMMMMMMMMQQQQQQQQQQQQQQQQQQQQQQQQQQQQQQ

Where CMY split the difference between RGB and H splits the difference between RGBCMY and M splits the difference between RGBCMYHHHHH, etc.

It can just be a colour service. Which I think you already laid out the frame work for. The only difference is that the colours shouldn't exist until they get into the division. And therefore for this to be done properly we need to move the colour to the meta object that holds the colour info and division location and pointer to data source. Then when we create one of those in the constructor we can just go "get next colour". The colour service can generate the colour on the fly from the above pattern on an as needed basis (lazy init).

Maybe I'll do this tomorrow, depending on how my other tasks go. Or maybe not, but it's now implemented in my mind :-)
User avatar (0000954)
Fred (administrator)
2011-12-10 15:35

We'll need a hook in the remove trace code that gives the colour back to the service (marks it available again) too.
User avatar (0000957)
Fred (administrator)
2011-12-10 16:24

My model doesn't allow white and shades of grey, either, however maybe they should be reserved for OLV use anyway, such as the mouse and centre markers, etc.

Also, custom colours need to be handled, it shouldn't be too difficult. Just do a search over the current used set, including custom, and choose the bisection points that have the largest span. White should be possible from a custom colour setter, and ignored in calculations because it's not possible to compare "distance" from it.
User avatar (0000959)
BenFenner (developer)
2011-12-10 16:45

In my mind, I envisioned a color service as you've described that has the ability to return the next best contrasting color (algorithm is a bit tricky, but not too hard) and all user-chosen colors get registered with it as well, so the next auto-assigned color takes the custom colors into account.
User avatar (0000961)
Fred (administrator)
2011-12-10 16:51

http://www.compuphase.com/cmetric.htm [^] !!! :-)
http://en.wikipedia.org/wiki/Color_difference [^] also worth reading, especially the 2000 section.

A simple distance from hue value and bisect algorithm would probably be a good place to start, though. You could seed the list with RGB and let it do the rest.
User avatar (0000963)
Fred (administrator)
2011-12-10 17:02

This could be useful for tabular data display too. There were reasons for your dislike of the purely hue based approach to rendering a 3d table if you read the above :-)
User avatar (0000966)
BenFenner (developer)
2011-12-10 17:31
edited on: 2012-08-04 14:46

Fred said: "A simple distance from hue value and bisect algorithm would probably be a good place to start, though. You could seed the list with RGB and let it do the rest."

This seems to be the first solution that pops into anyone's head when this problem is approached. It was the first thing I thought of as well. It has one serious flaw though.


Seed with R/G/B.
Current reserved colors: R/G/B

Want next best color?
Traverse the color wheel starting at Red and find three largest gaps in the color wheel (between Red and Green, between Green and Blue, between Blue and Red).
Traverse the color wheel again starting at Red and pick the first largest gap available.
Return color in the middle of Red and Green which is Yellow.

Current reserved colors: R/Y/G/B

Want next best color?
Traverse the color wheel starting at Red and find two largest gaps in the color wheel (between Green and Blue, between Blue and Red).
Traverse the color wheel again starting at Red and pick the first largest gap available.
Return color in the middle of Green and Blue which is Cyan.

Current reserved colors: R/Y/G/C/B

Want next best color?
Traverse the color wheel starting at Red and find one largest gap in the color wheel (between Blue and Red).
Traverse the color wheel again starting at Red and pick the first largest gap available.
Return color in the middle of Blue and Red which is Magenta.

Current reserved colors: R/Y/G/C/B/M

So far, so good. Now it starts to get bad...

Want next best color?
Traverse the color wheel starting at Red and find six largest gaps in the color wheel (between each of R/Y/G/C/B/M).
Traverse the color wheel again starting at Red and pick the first largest gap available.
Return color in the middle of Red and Yellow which is Orange.

Current reserved colors: R/O/Y/G/C/B/M

Want next best color?
Traverse the color wheel starting at Red and find five largest gaps in the color wheel (between each of Y/G/C/B/M).
Traverse the color wheel again starting at Red and pick the first largest gap available.
Return color in the middle of Yellow and Green which is Chartreuse.

Current reserved colors: R/O/Y/Ch/G/Cy/B/M

If you noticed (I'm trying to avoid doing this for another round to illustrate the problem), the last two colors returned are Orange and Chartreuse. These colors are WAY closer on the color wheel than some of the other available colors.

If you keep going eventually you get to the point where you're picking tons of shades of red before you even move on to oranges and then yellows and then greens. It gets to a point where you're picking colors that are VERY close to the color you just picked, because you're not jumping around the color wheel... You're traversing it from beginning to end.

Let me know if you want to chat more in IRC on this.

This is the one part of the algorithm I haven't been able to solve.

User avatar (0000968)
Fred (administrator)
2011-12-10 17:43

Although orange and chartreuse are not at all close, I do see your point. The solution has to be to find the set of next best colours and get the distance for each of them to each other and take the one with the highest minimum distance, yes, this will get slow at some point, but this runs so infrequently that it's TOTALLY fine for it to be slow :-)
User avatar (0000969)
Fred (administrator)
2011-12-10 17:44

Or to step around into different zones that are spaced 1/3 away each time, or something like that. In any case, it's definitely solvable, and the first 12 colours will be far enough away from each other to be usable if we do a naive impl up front.
User avatar (0000977)
Fred (administrator)
2011-12-11 02:31

http://sorsacode.com/color_wheel/ [^]

A neat little tool that Jammi knocked up earlier. Could be useful for experimentation with schemes.

Code: https://github.com/jammi/colorschemes/tree/master/hsv_palette [^]
User avatar (0001785)
BenFenner (developer)
2012-07-31 22:06

This got moved from target of "0.0.5" to "0.0.3".
User avatar (0001786)
BenFenner (developer)
2012-07-31 22:11
edited on: 2012-07-31 22:39

Some work on this completed in git hash: e04ef844d2373ec7ca3ba6411c2948c9885dcfc0

Default color selection is getting better. Completely new algorithm that actively looks for largest gaps in the color wheel. Everything has been simplified. I've removed an entire file/class/object in the process.

Much more work to come.

User avatar (0001789)
Fred (administrator)
2012-07-31 22:29

MUCH better, I think I may pitch a tent in celebration of the "assign on add" functionality.
User avatar (0001815)
Fred (administrator)
2012-08-06 12:01

I'm SOOOO looking forward to this!!! <3
User avatar (0001822)
BenFenner (developer)
2012-08-06 19:02
edited on: 2012-08-06 19:13

It is funny to read back through the old stuff. It turns out that right now the algorithm works exactly like the "simple" version described above in post #966, with the repetitive issue that comes with that. I have a plan to introduce some jitter/randomness into the color picking to avoid that problem, but for now the simple algorithm will have to do.

The main improvement now is that the colors are not chosen until the graph trace is actually added to the display. And when a graph trace leaves the display, it gives up its color properly for another trace to have if need be.

Colors specifically chosen and saved in the properties don't behave well with this color chooser yet.

The way the colors are added and removed just as the traces are added and removed is not exactly great, but that will get changed later.

Git hash incoming.

User avatar (0001823)
BenFenner (developer)
2012-08-06 19:10

Git hash: 3fac3b3bf540a986b2f0912dea9572fa80052340
User avatar (0001824)
BenFenner (developer)
2012-08-06 19:35
edited on: 2012-08-06 19:36

Some minor tweaks in this git hash: d37a6ad0b7a9d4ccb888c3788cb6153be1d56e88

Use null color instead of gray to denote an unchosen color. Also remove a setColor() method that was never used.

User avatar (0001825)
BenFenner (developer)
2012-08-06 20:33

Git hash: ed37caec79da03f98edf8f4fb8b94983473436e0

Get rid of the stupid Java 1.7 crap.
User avatar (0001826)
Fred (administrator)
2012-08-06 20:47

Tested in ed37caec79da03f98edf8f4fb8b94983473436e0 works great! Near the 10 mark a few similar greens show up, then more visually unique ones after that. I think this is down to the weighting of the distance algo, as some colours are naturally more similar to the eye than others.
User avatar (0001827)
Fred (administrator)
2012-08-06 20:48

If in future we improve it more, we should link to this issue, but create a new one. For now this is fine.


Copyright © 2000 - 2011 MantisBT Group
Powered by Mantis Bugtracker