mIRC Home    About    Download    Register    News    Help

Print Thread
Automatically colourize nicknames #266171 14/10/19 11:49 AM
Joined: Aug 2019
Posts: 12
afterdeck Offline OP
Pikka bird
OP Offline
Pikka bird
Joined: Aug 2019
Posts: 12
Consider the following screenshot:

[Linked Image from i.imgur.com]

How easy is to follow a conversation? /rhetorical/

Now, with colours:

[Linked Image from i.imgur.com]


...Can we please have automatic "colourization" of the nick-names in the chat and (maybe) in the user list as well?

Re: Automatically colourize nicknames [Re: afterdeck] #266172 14/10/19 03:03 PM
Joined: Oct 2018
Posts: 2
T
True_Falcon Offline
Bowl of petunias
Offline
Bowl of petunias
T
Joined: Oct 2018
Posts: 2
You mean like this?

https://imgur.com/a/9yOSW7C

Press alt-b to get the address book or right-click any name. It's also in the tools menu.

This is not new; I've been using it for years.

This particular chat room also give permission to certain users to post in colour as well!

Re: Automatically colourize nicknames [Re: afterdeck] #266174 14/10/19 08:10 PM
Joined: Dec 2002
Posts: 2,014
R
RoCk Offline
Hoopy frood
Offline
Hoopy frood
R
Joined: Dec 2002
Posts: 2,014
This can already be done. In mIRC type /abook -l

Here is mine.
[Linked Image from i.ibb.co]

Re: Automatically colourize nicknames [Re: afterdeck] #266175 14/10/19 10:12 PM
Joined: Jan 2004
Posts: 1,226
maroon Offline
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,226
This thread deals with that topic, and it doesn't look as cut and dried as you make it seem. How many colors should be assigned? How should they be assigned to the different nicks?

Depending on the background color, there can be different number of different colors you'd want to use. If your background is black, you could use 3-green 4-red 8-yellow 9-neon-green 11-sky-blue. But 2-blue would be bad. On the other hand, with a white background, 8/9/11 are bad, but 2 and 12 are good. Other colors start to become marginal, so how to decide when enough is enough.

Should the color be calculated based on the 'nick'? or their address so they stay the same color when they change nick? If the address, which mask should be used? Right now, your example looks like 3 nicks are using green, and a 4th uses a shade of blue that looks almost the same. It took me a while to figure out that bold meant that $1 was someone's nick.

Re: Automatically colourize nicknames [Re: maroon] #266201 19/10/19 02:45 PM
Joined: Dec 2002
Posts: 4,586
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,586
Quote
How many colors should be assigned? How should they be assigned to the different nicks?

Depending on the background color, there can be different number of different colors you'd want to use. If your background is black, you could use 3-green 4-red 8-yellow 9-neon-green 11-sky-blue. But 2-blue would be bad. On the other hand, with a white background, 8/9/11 are bad, but 2 and 12 are good. Other colors start to become marginal, so how to decide when enough is enough.

Should the color be calculated based on the 'nick'? or their address so they stay the same color when they change nick?

I tested several different algorithms that measure relative perceived luminance, contrast, etc. to determine if a foreground color is readable on a particular background color. It's not clear-cut but I found some algorithms that work reasonably well. The acceptability threshold has to be set high enough to disqualify unusable foreground colors for a specific background color, which unfortunately disqualifies a small number of usable foreground colors as well. But the overall result is acceptable.

To test this out, I made a small change to the nick color list feature so that if you add an item that has no color, it chooses a random color for the nickname. This seems like the easiest way of adding this feature, considering that there is no point in adding a no color item. It works as expected... all nicknames in the channel nick list are assigned random colors (based on a hash of their nickname) from the usable foreground colors list. You can then place this item in the order you want in the nick color list and it will only be applied if there are no other matches before it.

This could be made a default setting for newly installed versions of mIRC to improve readibility.

This will be in the next beta.

Update: It just occurs to me that there is a reason you would add a no color item... you could use it to block matching nicks from being colored by items further down the list. Hmm...

Last edited by Khaled; 19/10/19 10:57 PM.
Re: Automatically colourize nicknames [Re: Khaled] #266204 20/10/19 03:30 AM
Joined: Aug 2019
Posts: 12
afterdeck Offline OP
Pikka bird
OP Offline
Pikka bird
Joined: Aug 2019
Posts: 12
Originally Posted by Khaled

This could be made a default setting for newly installed versions of mIRC to improve readibility.
This will be in the next beta.


Excellent, looking forward to it!

Re: Automatically colourize nicknames [Re: Khaled] #266227 24/10/19 05:38 AM
Joined: Jan 2004
Posts: 1,226
maroon Offline
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,226
Observations on the new random colors:

0. Once the list/count of valid colors is known, is the hash method being used to assign colors from the list going to be public?

1. Minor bug: Right now, the color choices seem to be be reset only by clicking OK to exit the Alt+K dialog. If using "/color background N" to change between white and black backgrounds, the nick colors don't reset. But if you open Alt+K and click OK without doing anything in there, the colors do get re-assigned based on the earlier /color command.

2. People using this feature will need to have the channel and listbox backgrounds be the same color, because the color choices are based on contrast against $color(background), so some nicks in the nicklist could be hard to read against a different $color(listbox). There's no way around this without greatly limiting the valid colors, and I assume very few users want to have their nicklist and channel have different backgrounds.

3. There may be a few color combos that need to have a ban override. In the default theme "mIRC Classic", a blackground doesn't assign nicks to the color 48, but will assign 12 and 60 - but all 3 are equally illegible against a blackground:

//echo $chr(3) $+ 48,1 test48 $chr(3) $+ 60,1 test60 $chr(3) $+ 12,1 test12

4. While most colors chosen can be seen against the background they're supposed to contrast against, there's also the issue of contrasting between nick colors themselves. For example, against a white background these contrast against white, but not against each other.

//echo -a $chr(3) $+ 45,0 test45 nick=les $chr(3) $+ 46,0 test46 nick=troy

It would be much more time consuming trying to have a color set where every color contrasts well against each other, and for the most part it would be pointless because, removing a color from each pair of too-similar colors would just result in twice as many nicks being assigned the identical half-the-number-of-colors.

However, one improvement which could be made is to eliminate colors in index 0-15 which have been assigned RGB colors too close to a color in the 16-98 range, as well as pruning some 16-98 colors very close to each other.

In the default "mIRC Classic" scheme, this shows there are 6 colors in the 0-15 range which are duplicated in the extra colors range:

Code
//var %i 0 | while (%i isnum 0-15) { var %j 16 | while (%j isnum 16-98) { if ($color(%i) == $color(%j)) echo -a i: %i j: %j | inc %j } | inc %i }



result:
i: 0 j: 98
i: 1 j: 88
i: 4 j: 52
i: 8 j: 54
i: 11 j: 58
i: 13 j: 62

When the background is white, it looks like there's currently 67 colors chosen as nicks, so by assigning some nicks as color 1 and others as colors 88, it causes more black-ish nicks than there should be, because effectively 88 is used twice as often as every other RGB except for 62's.

There are other color pairs where the item in the 0-15 range could be dropped if it's too close to the color in 16-98. For example 14 vs 94 is rgb 127,127,127 vs 129,129,129

Among the extra colors, I don't know how slow this would make building the colors list, but something like this could identify colors very similar to each other, and whichever contrasts best against the background could be the one kept.

Code
//var %i 16 | while (%i isnum 16-98) { var %j %i + 1 | while (%j isnum 16-98) {  tokenize 44 $rgb($color(%i)) | var %r1 $1 , %g1 $2 , %b1 $3 | tokenize 44 $rgb($color(%j)) | var %r2 $1 , %g2 $2 , %b2 $3 | var %dist $calc( (%r1 - %r2)^2 + (%g1 - %g2)^2 + (%b1 - %b2)^2 ) | if (%dist isnum 1-1999) echo -a dist %i %j %dist | inc %j } | inc %i }



I assume a 'real' algorithm would assign different weights to RGB.

5. People with color-blindness, which google claims affects 8% of males, would probably be avoiding this feature. While they can adjust the RGB for index 0-15, they don't have control over the random choice of greenish vs reddish shades from the 16-98 range.

6. For those wanting to test the random colors, this is the alias I use to see which colors are chosen against various backgrounds, and to see who is assigned the same index as my nick. The color for each nick almost always changes when the background changes, because there's a different count of colors not-chosen. And reminder to forum users that the .color property of $nick() can be used to identify the color chosen.

Code
//var %chan #freenode , %t $nick(%chan,0) , %i 0 , %a $str(0 $chr(32),99) | while (%i < %t) { inc %i | var %n $nick(%chan,%i) , %c $nick(%chan,%i).color , %c2 %c + 1 , %new.val $gettok(%a,%c2,32) + 1 , %a $puttok(%a,%new.val,%c2,32) | if (%c == $nick(%chan,$me).color) echo -s %n %c } | echo -s background: $color(background) zeroes: $wildtok(%a,0,0,32) of 99 total: %t : $regsubex(foo,%a,/(\S+)/g,$+($calc(\n -1),:,\t,$chr(32)))


Re: Automatically colourize nicknames [Re: maroon] #266229 24/10/19 08:16 AM
Joined: Dec 2002
Posts: 4,586
Khaled Offline
Hoopy frood
Offline
Hoopy frood
Joined: Dec 2002
Posts: 4,586
Quote
1. Minor bug: Right now, the color choices seem to be be reset only by clicking OK to exit the Alt+K dialog. If using "/color background N" to change between white and black backgrounds, the nick colors don't reset. But if you open Alt+K and click OK without doing anything in there, the colors do get re-assigned based on the earlier /color command.

Thanks this has been fixed for the next beta.

Quote
There may be a few color combos that need to have a ban override.

There are no plans to add such a feature. If you can find a foreground/background color combination algorithm that works better than the current one, I would be happy to use it though.

Quote
However, one improvement which could be made is to eliminate colors in index 0-15 which have been assigned RGB colors too close to a color in the 16-98 range, as well as pruning some 16-98 colors very close to each other.

I should be able to add this to the next beta. In fact, it should exclude any color value that is already in the usable colors list, not just the color index.

Thanks for your other comments.

Re: Automatically colourize nicknames [Re: Khaled] #266256 29/10/19 11:13 AM
Joined: Jan 2004
Posts: 1,226
maroon Offline
Hoopy frood
Offline
Hoopy frood
Joined: Jan 2004
Posts: 1,226
I tried to do a 'what-if' test using the contrast formula at
https://ux.stackexchange.com/questions/107318/formula-for-color-contrast-between-text-and-background
and it looks like that's how the random color palette is currently being chosen. It appears that the blue/black combos I mentioned in the prior post are caused because the random nick colors use the color indexes with scores of approx 2.3 or higher. The formula at the url seems less accurate when blue is involved either as the foreground or background. Index 60 and mIRC Classic's index 12 both have scores of approx 2.4 against a black background, which is barely higher than the 2.3 selection cutoff.

//echo -a $contrast(1,12) $contrast(1,60)

Also, against blackground, the formula gives 12 and 60 slightly better contrast scores than index 29, but 29 is much easier to read than the others. Similarly, 74 and 84 have very similar scores against white, but 74 is much easier to see than 84.

Perhaps someone else more familiar with luminosity/contrast formulas could suggest a better tweak of the formulas generating the contrast score, but perhaps a configuration option where people can indicate which minimum contrast score they wish to use. People with different eye compatibility can choose between having more random colors, or fewer colors which tend to exclude colors harder to see against the chosen background. By bumping the cutoff score from 2.3 up to 2.5, that eliminates several poor contrast combos like:

//echo -a $chr(3) $+ 12,1 test12 $chr(3) $+ 12,1 test60 $chr(3) $+ 84,0 test84

For the alias below, "/test_contrast 2.3" imitates the colors I see currently chosen for white and blackgrounds. "/test_contrast 2.5" shows an alternate colors choice where a black background doesn't choose the hard-to-see blues.

"/test_contrast 2.5 999" includes the option where it looks for close matches between 0-15 and 16-98. It currently tosses the higher index number instead of whichever has the better contrast.

The $lum and $brightness aliases are borrowed from the Xpalette forum post.

Code
; $1 is index 0-98
alias Lum {
  tokenize 44 $rgb($color($1))
  return $calc(0.2126 * $brightness($1) + 0.7152 * $brightness($2) + 0.0722* $brightness($3))
}
alias brightness {
  var %res = $1 / 255
  return $iif(%res <= 0.03928, $calc(%res / 12.92), $calc((( %res + 0.055) / 1.055) ^ 2.4))
}

; $1 and $2 are 2 color indexes 0-98
alias contrast {
  var %a k0,x color x k1,x color x k0,y color y k1,y color y . kx,y color x on y ky,x color y on x .
  echo -s $replace(%a,k,$chr(3),x,$1,y,$2)
  clipboard $replace(%a,k,$chr(3),x,0,y,1)
  tokenize 32 $sorttok($Lum($1) $Lum($2),32,nr)
  return $calc( ($1 + 0.05) / ($2 + 0.05) )
}

; any channel with many nicks will do
alias test_contrast {
  var %chan #freenode , %t $nick(%chan,0) , %i 0 , %nick.buckets $str(0 $chr(32),99)
  while (%i < %t) {
    inc %i | var %n $nick(%chan,%i) , %c $nick(%chan,%i).color , %c2 %c + 1
    var %new.val $gettok(%nick.buckets,%c2,32) + 1 , %nick.buckets $puttok(%nick.buckets,%new.val,%c2,32)
    ; next line just shows everyone having same color as yourself
    ; if (%c == $nick(%chan,$me).color) echo -s %n %c
  }
  var %bg $color(background) , %fg $color(normal) , %rgb.taken $color(%bg) , %lum.bg $lum(%bg) , %rgb.0-15
  var %threshhold 2.3 | if ($1 isnum 0-) var %threshhold $1
  var %min.dist 0     | if ($2 isnum 0-) var %min.dist $2
  var %i 0 , %yes.now , %nno.now $chr(3) $+ 0 $+ , $+ %bg , %alt.yes , %alt.nno %nno.now , %lum.array
  while (%i < 99) {
    var %j = %i + 1
    var %lum.i $lum(%i) , %lum.array %lum.array %lum.i
    if ($istok(%rgb,$color(%i),32) ) { echo -s toss %i is a dupe | inc %i | continue }
    var %rgb %rgb $color(%i)
    var %tmp $sorttok( %lum.i %lum.bg ,32,nr)
    var %tmp $calc( ( $gettok(%tmp,1,32) + 0.05) / ($gettok(%tmp,2,32) + 0.05) )

    if (%min.dist) {
      if (%i < 16) var %rgb.0-15 %rgb.0-15 $rgb($color(%i))
      else {
        var %c 1 | while (%c isnum 1-16) {
          tokenize 44 $gettok(%rgb.0-15,%c,32) $+ , $+ $rgb($color(%i))
          var %dist $calc( ($1 - $4)^2 + ($2 - $5)^2 + ($3 - $6)^2 )
          if (%dist < %min.dist) { var %tmp , %diff $v1 | break }
        inc %c }
      }
    }

    if (%tmp == $null) { echo -s toss %i close to $calc(%c -1) . $rgb($color(%i)) vs $rgb($color($calc(%c -1))) . dist %dist | inc %i | continue }
    var %label $+($chr(3),%i,test,%i,=,%tmp)
    if ($gettok(%nick.buckets,%j,32) == 0) var %nno.now %nno.now %label , %nno.contrasts %nno.contrasts %tmp
    else                                   var %yes.now %yes.now %label , %yes.contrasts %yes.contrasts %tmp
    if (%tmp > %threshhold)                var %alt.yes %alt.yes %label
    else                                   var %alt.nno %alt.nno %label
    inc %i
  }
  echo -s ===== nicks in use: color|nick_count|luminosity
  echo -s background: %bg zeroes: $wildtok(%nick.buckets,0,0,32) of 99 total: %t : $regsubex(foo,%nick.buckets,/(\S+)/g,$+($calc(\n -1),:,\t $+ $chr(22) $+ $round($gettok(%lum.array,\n,32),3) $+ $chr(22) ,$chr(32)))
  ;echo -s ===== sorted contrasts vs background
  ;echo -s yes.contrasts: $sorttok(%yes.contrasts,32,n)
  ;echo -s nno.contrasts: $sorttok(%nno.contrasts,32,n)
  echo -s ===== colors     used and their contrast vs background
  echo -s $numtok(%yes.now,32) now.yes: %yes.now
  echo -s ===== colors NOT used and their contrast vs background
  echo -s $numtok(%nno.now,32) now.nno: %nno.now
  clipboard %nno.now
  if (%threshhold != 2.3) {
    echo -s ===== what-if colors and their contrast vs background contrast: score > %threshhold
    echo -s $numtok(%alt.yes,32) alt.yes: %alt.yes
    echo -s $numtok(%alt.nno,32) alt.nno: %alt.nno
  }
  echo -s ===== $ $+ 1 == optional min contrast score (default 2.3) $ $+ 2 = optional 16-98 min distance vs 0-15 RGB (default 0 suggest 1000)
}
; $1 and $2 are index 0-98
alias distance {
  tokenize 44 $rgb($color($1)) $+ , $+ $rgb($color($2))
  return $calc( ($1 - $4)^2 + ($2 - $5)^2 + ($3 - $6)^2 )
}