Re: InSight IML Content Description (PLEASE READ)

[raster redhat com]

On 13 Feb, Miroslav Silovic shouted:
->  
->  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.

That was my thought.. ontop of any current rendering...

->  > > 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

On a greyscale image this actually works.. the image just determines the
value - the rgb modifiers modify this to give any hue you like.. :) that
was my point... and it was a simpler transform... :)

->  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;

Ahh the ever useful bit-shift... :) yup I'd do it that way. (actually
I'd do >> 16 and use a as a 16-bit angle value for more accuracy - no
loss of speed).

->  (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. :) )

Actually easy.. Imlib uses simple pixel arrays :) I'd actually want to
add this into each render function (now you hear "OH no - not MORE
render functions!") I'd do the shift on-the fly when rendering the
pixmap just as I do for the gamma, brightness, contrast and mapping
table stuff - it can be applied to the image at any time. This will
much more easily allow "realtime" adjustment via widget controls.

->  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.

Actually not really.. Imlib's cache is smart enough to realise an
Image's "mapping" table (currnetly the RGB tables) have changed - that's
the reason electriceye's contrast etc. ontrols work at all.. otherwise
Imlib's caching would prevent the pixmap from changing... :)


-- 
--------------- Codito, ergo sum - "I code, therefore I am" --------------------
raster@rasterman.com       /\___ /\ ___/||\___ ____/|/\___  raster@redhat.com
Carsten Haitzler           | _ //__\\ __||_ __\\ ___|| _ /  Red Hat Advanced
218/21 Conner Drive        || // __ \\_ \ | |   \ _/_|| /   Development Labs
Chapel Hill NC 27514 USA   ||\\\/  \//__/ |_|   /___/||\\   919 547 0012 ext 282
+1 (919) 929 9443, 801 4392   For pure Enlightenmenthttp://www.rasterman.com/