I don't think RGB=>HSL conversion calculation is a complicated affair
(I had a look at the Google styledMaps Wizard code), but even having a
correct conversion technique will be pointless until we can figure out
what google maps server does with the 'hue' option... all we know for
now is that Google:
... accepts and understands '0x' ('xff0000' fails, '0zff0000' fails,
'ff0000' alone fails)
... yet '#' and '0x' trigger different behaviours (#ff0000 renders
red, 0xff0000 renders blue)
... accepts and understands 'pure hue' input (any number with or
without '#' or '0v' works)
... yet '225' renders magenta, '#225' renders blue, and '0x225'
renders purple
... the server strips all leading zeroes in '0000225' (renders the
same as '225') and '0x0000225' (ditto as '0x225')
... and that any 'hue number' longer than 9 characters (after a '0v')
will override any mix with 'Google colours'.
No matter what number you put as a hue, I think that the 'HSL hue
calculation engine' extracts only the 'pure hue' from the RGB
hexadecimal and passes the 'remainder' to the lightness and saturation
elements of HSL. For example, pure red in RGB (#ff0000) is H 0 (0º) S
1 (100%) L 0.5 (50%) - we can assume that the 100% saturation and 50%
lightness are the passed on remainders.
Add to the above mix the fact that even the 'pure hue' number is a
degree ~away~ from google's existing colour scheme for that element,
and we've got a... mess.
I still don't know what to conclude from yesterday's 'discovery':
0xF0F03600
0xFFF00000 == #FF0000
0xF0FF0000
...because 0xF0F000010 (one degree to the right of 0xF0F03600) renders
a completely different colour. Actually I think the leading four
characters set the 'zero point' on the wheel ('FOFO' indicates that
zero is pure green), and '360' is the degrees away from that point.
But the '360' doesn't make any sense at first glance - that's a full
rotation! Yet '0xF0F0720' - 720º away from the 'green point zero' -
renders... pure blue. Yet '0xF0F01080' renders #00FF88 (greenish
blue). Wwwhat?
On Aug 25, 12:28 am, William <[email protected]> wrote:
> On Aug 25, 12:34 am, Sefu <[email protected]> wrote:
>
> > I'm sure google wants people to make plans that can be visually
> > associable with their base product - and their method is a good means
> > to that end. Especially their RGB to HSL calculations... grrr.
>
> wow you've discovered a lot about the RGB --> HSL calculations! To be
> honest I'd never looked at the HSL color system before this, and it's
> not as straightforward as the RGB or CMYK system.
>
> I'd like to see a pure HSL option with the styled maps, where the user
> can either specify the hue as:
> 1. RGB as it is done now with a #, or
> 2. as a pure hue from 0 to 360.
>
> That would avoid the need for translating from RGB to HSL for cases
> when the graphic designer already knows the hue they want to use? I'm
> no expert in graphic design but I can see that Photoshop makes it easy
> if you want to use HSL, so I'm not sure why RGB was chosen for hue in
> the maps API?
>
> I made a feature request for
> this:http://code.google.com/p/gmaps-api-issues/issues/detail?id=2665
>
> ...
--
You received this message because you are subscribed to the Google Groups
"Google Maps JavaScript API v3" group.
To post to this group, send email to [email protected].
To unsubscribe from this group, send email to
[email protected].
For more options, visit this group at
http://groups.google.com/group/google-maps-js-api-v3?hl=en.
