Re: InSight IML Content Description (PLEASE READ)

[Miroslav Silovic <silovic zesoi fer hr>]

I'm answering both posts with this one.

Bowie Poag <bjp@primenet.com> writes:

> Easy is the operative word here, I agree. Although I dont know how to
> code it, I know that performing hue-shifts of reigons of data as small as
> the one's we're dealing with can be done in realtime with little effort.
> That was the whole crux of color-reactiveness in InSight's (proposed)
> desktop.. That we -would- have that computational horsepower available to
> us to perform a dozen hue shifts on a dozen tiles in realtime.

Right. Almost anything will work on images 64x64 or smaller. Although
when you have *many* icons to colorize (such as files in a large
directory), it may become significant.

> > Remember - just because it's in the GIMP does not mean it's practical
> > for a GUI in general.. some things GIMP does are great for art - but
> > fairly expensive computationally - and not he thing you want to do on a
> > regular basis.

The problem here is that you can't do correct hueshift just by
changing each RGB channel separately - hueshift involves interactions
between channels. Actually HSV hueshift remapped into RGB space looks
like one of these:

r = a * r + (1-a) * b
g = a * g + (1-a) * r
b = a * b + (1-a) * g

---or---

r = a * g + (1-a) * r
g = a * b + (1-a) * g
b = a * r + (1-a) * b

---or---

r = a * b + (1-a) * g
g = a * r + (1-a) * b
b = a * g + (1-a) * r

(r, g, and b are color components in the pixel, a is mixing factor
(between 0.0 and 1.0, and you choose first, second or third set of
equations depending on whether your hue shift is by 120, 120-240 or
240-360 degrees in the hue space. Or course, this needs to be
optimized for integer calculation... Probably something like

r = (a * r + (256 - a) * b) >> 8;

(note that multiplication is faster than table lookup on most modern
CPUs, as integral multiplication doesn't involve memory access).

Hmm, actually I like this idea better than converting to HSV and back.
The basic math would look like this (I slightly debugged it from the
above, I just don't feel like rewriting the pseudocode :) ):

typedef struct {
    unsigned char r, g, b;
} Pixel;

/* angle is given as 0..255 */

void colorize_pixel_array (Pixel *array, int number_of_pixels, int angle)
{
    Pixel out;
    int i;
    int conversion_type;

    angle *= 3;
    conversion_type = 0;
    if (angle > 256) {
	conversion_type++;
	angle -= 256;
	if (angle > 256) {
	    conversion_type++;
	    angle -= 256;
	}
    }
	
    for (i = 0; i < number_of_pixels; i++) {
	Pixel *p = array + i;

	switch (conversion_type) {
	case 0:
	    out.r = ((256 - angle) * p->r + angle * p->b) >> 8;
	    out.g = ((256 - angle) * p->g + angle * p->r) >> 8;
	    out.b = ((256 - angle) * p->b + angle * p->g) >> 8;
	    break;
	case 1:
	    out.g = ((256 - angle) * p->r + angle * p->b) >> 8;
	    out.b = ((256 - angle) * p->g + angle * p->r) >> 8;
	    out.r = ((256 - angle) * p->b + angle * p->g) >> 8;
	    break;
	case 2:
	    out.b = ((256 - angle) * p->r + angle * p->b) >> 8;
	    out.r = ((256 - angle) * p->g + angle * p->r) >> 8;
	    out.g = ((256 - angle) * p->b + angle * p->g) >> 8;
	}

	*p = out;
    }
}

(yes, this would need some porting to work with Imlib datatypes. :) )

This is probably as fast as it can possibly be and I think it creates
less overhead than, for example, dithering.

> Agreed. Although hueshifts would have been performed in realtime, the
> set of numbers (hue/sat/lightness) of the icon had the ability to be
> cached for future application. Those of you who are familliar with

Caching becomes a problem when you have a reason to color every icon
individually. For example, if you colorize by filesize, then it's
likely that every file will have a different color. It'd work well
for beacons and lamps, though.

-- 
I refuse to use .sig