Notes
(0032591) Ken Moreland (manager) 2014-04-14 21:58	I believe this behavior was originally intended. The number of labels is really a hint. The color bar labeler can change the number of labels to make more human readable numbers. Since the last version of the color bar was written, there has been some research papers published in IEEE Vis dealing with making good labeling on chart axes (which is really the same problem). If anyone wants to revisit how these labels are created, this literature should be reviewed.

(0032594) Alan Scott (manager) 2014-04-15 11:55	To quote Dumbledore, yes - and no. The bug listed here is truly a bug. If you repeat the steps above, then play around with the number of labels count, it will get unstuck, and start to follow the suggested label count. Further, it makes sense to me that it should always follow the count if you suggest fewer labels, but not necessarily more (due to space constraints).

(0032596) Ken Moreland (manager) 2014-04-15 13:33	I disagree that it should always follow the count if there is room. Most counts will lead to pretty ugly and worthless numbers in the labels. For example, assume you have a range from 0 to 100. If you force having 10 labels, you get the labels 0, 11.111, 22.222, 33.333, 44.444, 55.555, 66.667, 77.778, 88.889, 100. Even though there is probably enough room for these labels, ParaView does the right thing by reducing the number to 6 and giving 0, 20, 40, 60, 80, and 100. Thus, I'm pushing back to be careful about how to fix this bug (if it's fixed at all). What you describe can be considered a bug, but the consequence of this poor behavior is much, much lower than the potentially bad side effects that can pop up by fixing it. In fact, the current behavior looks about right to me. It appears to be treating the label count as a maximum number of labels to use and then using the most labels equal or below this value that produce nice numbers (i.e. numbers that can be represented in few significant bits in base ten). The confusion appears to be that this count of labels seems to sometimes include the min and max and sometimes does not depending on whether the min/max are considered nice or not. The behavior could be changed to never include them to remain consistent. If that is not good enough, I once again encourage someone to look through recent literature on axes label placement. The solution is not as simple as making the color bar show the number of labels requested by the user, and I'm going to be pretty unhappy if the color bar labeling gets f*@#ed up.

(0032597) Alan Scott (manager) 2014-04-16 13:01	OK, amazingly, you have convinced me. There is a bug in there, but lets call it trivial. (If you start counting down, 4, then 3, then 2, nothing happens. At 1, the color bar annotation changes. Going back to 2 doesn't repeat what you saw before with 2).

(0032598) Alan Scott (manager) 2014-04-16 13:05	Closing this bug. I am mixing two issues - 1) number of labels, which the code should (and does) try to make as logical as possible, and 2) the ability for a user to manually set their own color legend labels. I will either resurrect an old bug, or create a new one. Closing this one.

Issue History
Date Modified	Username	Field	Change
2014-04-11 21:01	Alan Scott	New Issue
2014-04-11 21:02	Alan Scott	Product Version	=> git-master
2014-04-11 21:02	Alan Scott	Relationship added	child of 0014679
2014-04-12 22:08	Utkarsh Ayachit	Target Version	=> 4.2
2014-04-14 21:58	Ken Moreland	Note Added: 0032591
2014-04-15 11:55	Alan Scott	Note Added: 0032594
2014-04-15 13:33	Ken Moreland	Note Added: 0032596
2014-04-16 13:01	Alan Scott	Note Added: 0032597
2014-04-16 13:05	Alan Scott	Note Added: 0032598
2014-04-16 13:05	Alan Scott	Status	backlog => closed
2014-04-16 13:05	Alan Scott	Assigned To	=> Alan Scott
2014-04-16 13:05	Alan Scott	Resolution	open => fixed