Jens Scheidtmann wrote:
> > > So you want to have them as visually distinct as possible.
> >
> > Hell no :-)! I'd like them to be different shades, to aid in visually
> > discerning matched strings. But I'd like to have different meanings
> > for different colours. Keeping the explanation as simple as "red
> > means removed, yellow means added, green is the same (might have been
> > moved around)" appeals to me.
>
> Yes, good point, but ...
>
> >
> > Can you provide any good examples where it is vitally important to
> > have extremely contrasting colors?
>
> ... I often have to deal with very long lines in source code, where
> only some characters or words have been (ex)changed. In this case
> colors giving a black eye are really handy: You just scroll within
> TMerge from left to right and by these colors you are forced to look
> at the place where it has changed. Using different shades of green
> would make this more difficult. For me the information what's new and
> what's been left out is not so important, as this is IMOH an
> infrequent case for changes within lines (you drop some lines here and
> insert some more lines there, but that's account for differently).
>
> So the color differences should at least be easily spottable.
> And yes, maybe the colors have much to much contrast.
>
> Best would be (if you want to have them similar) to place a reference
> point in CIE L*a*b*, where euclidian distance is proportional to
> percepted color difference and place 5 - 11 colors (odd) around that
> reference point. Then enumerate these points so that the sequence has
> maximum color differences (for 5 points --- hope you don't use a
> proportional font):
>
> 1
>
> 4 . 3
>
> 2 5
>
> (You should do that in three dimensions taking luminance into account
> ;-)
Jens, thank you very much for the information.
Some experts are of the opinion that the euclidian distance between
colours in CIE L*a*b* is bogus when it comes to measuring perceptually
uniform colors.
Here's an example:
http://www.aim-dtp.net/aim/evaluation/cie_lab/
Care to comment on exactly *how* bogus it is?
Also, do you know of any colour-picker program suitable for choosing
colors with high color-difference but a low cataracts factor that you
could recommend for the job at hand?
> BTW, if you have a look at
> http://en.wikipedia.org/wiki/Lab_color_space you'll see that green is
> not a good choice, because the eye does not differentiate bright green
> colors well. (See http://www.cs.rit.edu/~ncs/color/t_convert.html for
> conversion formulas to RGB)
Oops.
Well, I like the "use shades of gray for fore-color" idea just as
well, seeing as it would keep the background color for unchanged lines
the same as is used in the diff windows (white).
How's that? Better or worse?
> But maybe the problem does not lie in the colors but in the algorithm:
> The algorithm has no notion of "relevant changes", it treats
> all substrings the same. Maybe something like a visualization of
> minimum edit distance (Levenshtein distance) would be more
> appropriate, but I haven't found good references on that yet (only the
> calculation of minimum edit distance).
Brilliant idea.
Let's spare ourselves the trouble and not do that and just say we did :o).
Oh, and a last question, out of pure interest.
You seem to do some professional diff'ing - are you actually using
TMerge for it, or do you use some other solution?
---------------------------------------------------------------------
To unsubscribe, e-mail: dev-unsubscribe@tortoisesvn.tigris.org
For additional commands, e-mail: dev-help@tortoisesvn.tigris.org
Received on Tue Mar 22 21:06:26 2005