[rescue] Spaceballs.

[Joshua D Boyd]

On Fri, Dec 07, 2001 at 10:05:50PM -0500, Dave McGuire wrote:
> On December 7, Joshua D Boyd wrote:
> > Hmm.  Well, if you view color as a vector <r, g, b, 0> (or should that be a
> > 1?), then you can use a matrix to transform it.
> > 
> > For instance, pushing the ball around would create translation matrices inside
> > the RGB vector space.  Rotating the ball would generate rotation matrices. 
> > Not sure how one would create scaling matrices from the ball input.  
> > 
> > Anyway, this would mean that you could rotate and move the colors around in
> > presumably interesting ways for adjustment.  One could allow one of the buttons
> > on the space ball to put you in a mode for doing color space projections, and 
> > warping, shearing.  
> 
>   That sounds *very* cool...feel free to expound if you're so inclined...

Well, basically, I've paid a lot of attention whenever I could to what makes
the colors and such on movies pop.  It obviously is more than just tweaking the
color balance and contrast in programs like Photoshop.

About the single most interesting thing I've learned along the way is that you
don't have to be precise for it to look good (usually).  Also, there is a lot
of value to treating the 3 colors as 3 dimensions.  I saw this mentioned in 
some papers put out by SGI, but it didn't really sink in until I took a linear
algebra class (not required at my school, but I thought it would be usefull).

Basically, I use 3x1 or 4x1 matrix to represent each pixel.  When I say 4x1, I
mean something like <r, g, b, 0> or <r, g, b, 1>.  4x1s are convienient for 
many reasons.  A large one being that 4x1s are used a lot in 3D graphics, so
there is a lot of code out there.  I don't remeber off the top of my head 
whether the last element should be 0 or 1.  However, it occurs to me that while
I'm at it, I should try setting the last element to the transparency.  This may
or may not have interesting results, but I'm getting off track here.

Anyway, if we treat each pixel as a 4x1 matrix, then if we want to add dR extra
red, dG extra green, dB extra blue, then we would just use the matrix:

1 0 0 dR
0 1 0 dG
0 0 1 dB
0 0 0 1
and multiply each pixel by that matrix.  One benefit of viewing it this way is
that now it becomes dirt simple to use things like Altivec or 3DNow for certain
imaging operations.

Anyway, we can also now scale the range of each color.
0.5 0   0   0
0   0.5 0   0
0   0   0.5 0
0   0   0   1
would have the effect of compressing the color range to half.  We could then
multiply this matrix by the above translation matrix to move the colors to a 
more desireable range.  I suspect that sometimes when a seem is rather bright,
they may have done something like this.

We also can do rotate a pixel around an arbitrary axis in the color space.  
What this means visually, I don't know, since I'm not yet this far.  I still
building the framework to carry out these experiments on.

Also, changing color spaces altogether (say from YUV or HSV to RGB) is also 
just another matrix multiply.  This means that I don't need to do a lot of 
work to allow YUV operations.  This means that I can create a matrix that does
an HSV rotation (I don't know what that looks like either), multiply it be a 
matrix that converts HSV operations to RGB operations, etc.

Now, another interesting side trail that I haven't explored yet would be
color curves.  They pop up in a number of programs.  Bezier curves seem to be 
the most common.  They are easy to represent in 4x4 matrices.  I wonder what 
how it works to use a bezier curve to adjust a color range.  I suspect that it
is just the creation of another 4x4 matrix to place on the stack.

Now other areas for color work would be using FFTs on them.  I've long 
understood FFTs in the context of sound, but I'm slowly getting a handle on 
what they mean in the context of graphics.  FFTs can be used for interesting
effect for picking the detail of an image appart from the shading.  Basically,
(I got this from an article in a game programming magazine interestingly), I 
can use a FFT to split an image into to layers, a high frequency layer, and a 
low frequency layer.  The two layers summed are the original image.  However, 
now I can edit them seperately for interesting effect.

Anyway, the possibilities are pretty limitless.  I'm trying to get basic 
framework, and some basic stuff done now before I worry about the really wild
stuff.  Some of my greatest inspirations come from reading tutorials and user 
manuals for really high end programs like inferno* and color*star etc.

All summing related activities can definately be done in hardware on SGIs 
(especially easy on SGIs with large texture buffers, like O2s, hence my 
obsession with O2s instead of Max Impacts).  The rest of it, I'm not exactly 
sure.  You do can potentially get a speed boost by doing an operation and 
storing the results of the operation in a new buffer, then subtracting the 
original one from the new one, and then layering the two.  This would slow
down doing operations, but it would greatly speed up undos, and plus could 
allow for applying new operations only to the change in the image rather than
the image as a whole without redicuslous redraw speeds.  Everyone associates
SGIs with great 3D performance, but what really sets them appart in my eyes is
that they truly embrace the idea of OpenGL being for everything, and design
their hardware to reflect this.
	
When I actually get something working that people could play with, I can try
and find web space to post it.  I have no idea when I will get major progress
though.  I am doing pretty much everything in OpenGL, making it extremely 
portable, but also most likely very problematic for any PC user (windows, 
linux, MacOS X) who has a video card different from mine, since pretty much all
the PC video card makers have crappy OpenGL.  Nvidea does seem to be the best
though, quality wise (and pretty much clearly speed wise).  I'd be intersted in
someday trying the code out on a midrange SB100.  Mainly if I ever try to 
commercialize it.  SGIs are great, and things would probably go faster if I 
could develop on them, but ultimately, O2s are too expensive to try and ship
a midrange product on.  But, I probably would never try to ship this anyway, 
(although my own visual effects/effects software company is a bit of a dream) 
so the SB100/new O2 price issues are probably mute.

 
> > This actually is related to something else I'm working on.  Since I don't have
> > a space ball, obviously I'm not using it for this though.
> 
>   Sounds like you need to get one! :-)

Well, I really want one for the solids modelling/model painting project I want
to do.  But, for the color space stuff, I don't think that it would be anything
more than a gimick.  Still, I probably would try it when I manage to get one.

Early this summer, most spaceballs (even the really old 2003s) were close to 
$70-$80.  That is just a bit beyond my buy it on a whim limit.  Still, I bid
on a few, but always lost in the last hour or so.  Anyway, the prices have
fallen a lot now, but I can't spend a penny more then needed until I get my car
situation worked out (can get a loan for a new one, but not quite enough of a 
loan, and repairing the old one, well I'm within $50 on either side of being 
able to repair it, and that is without holding any money back for christmas 
presents.  People will understand, but I really want to find a way to get me GF
one anyway).  

Almost everything that can be wrong with a clutch is wrong with mine.  The
clutch needs to be replaced.  The cable needs to be replaced, the rear seal
needs to be replaced, and the clutch pedal assembly especially needs to be 
replaced.

-- 
Joshua D. Boyd