Trans / Color Modifer freakyness (justin?)

UnConeD

13th September 2003 16:03 UTC

Trans / Color Modifer freakyness (justin?)
I'm still trying to wrap my head around trans color modifier. It's obviously not a per-pixel code evaluator, because that should be dead-slow, and the CMo* isn't.

Here's where the problems start...

Example 'Solarization' (this is a chrome filter btw)
red=(min(1,red*2)-red)*2;
green=red; blue=red;

If we view this piece as something that gets executed like in a superscope, then the result is incorrect. The final two statements cause red to equal green and blue, so the result would be a grayscale image. But it isn't.

So here's what I think the CMo does...

The init, frame and beat codes are run like any other component, though are only really useful if you use "recompute every frame".

The level code is run 256 times once, with a 256-shades grayscale ramp as the input. In the beginning of the code, red=green=blue. So the input/output has nothing to do with the pixels in the image, but rather defines a general transformation for colors.

The output is a 256-color palette, which can be seen as 3 color maps which each operate only inside their own channel: one for red, one for green, one for blue.

Imagine a colormap APE where there are 3 gradients rather than one, but the first gradient is limited to pure red colors, the second gradient to pure green colors, the third to pure blue colors.
Per pixel, the color is split into channels: red, green, blue.
Each is used as an index into one of the colormaps (red for the first, green for the second, blue for the last). The values in the Rgb channels are replaced by their respective mappings in their gradient.
Then the result is assembled back into a pixel and written out.

So that explains why the solarization code works. If the input is RGB(150,150,150), it will first calculate the solarization of the red component. That's 210. Then it sets the same value for the green and blue component. The output is RGB(210,210,210).
If we do this for every grayscale input, the three channels of the output pallete will contain the solarized version of their value.

By applying these 3 solarization maps to an RGB pixel, we get a per-channel solarized version.

So what is the use of mixing channel inputs, e.g. using something like 'green=red+.5'? It won't work as a channel shifter, it simply results in 'use the same colormap for the red channel as for the green channel, except add .5 brightness to it aswell'.

(*) I suggest CMa for color map, CMo for color modifier ;).

justin

13th September 2003 16:45 UTC

That's right, it just creates three tables in one pass, each table a remap for each channel. The reason you can't do full channel mixing is that the table that you would need to generate for that would be rather large.

Now, you could do it with reduced precision and interpolation, but I'm not sure that would be terribly useful.

Anyway, so yeah it just goes through the loop, each time setting
red, green, and blue from 0.0 to 1.0. Then you can modify what
the output for each of those channels are.

So you think we should rename it to Channel Modifier or Color Map
or something?

-Justin

UnConeD

13th September 2003 16:50 UTC

Hm? You don't seem to know this... Color Map already exists, it's an APE I made with similar functionality to Color Modifier, except it's not code driven, and uses only one index for lookup. Get it here.

Have you missed out on other APE goodies too, like Texer, Convolution (by Tom Holden), Multiplier, Channel Shift, ... ? Couldn't immediately find links for them, but you can get most of my APEs by downloading Whacko AVS V and VI (though you should keep the more recent colormap above).

justin

13th September 2003 16:54 UTC

No I have seen it (it's nice, too)... I just meant, hmm, maybe we should rename modifier... Anyway I'm gonna update 270pre soon with a bunch of little fixes, hehe.

BTW, I can't seem to duplicate old presets with Trans / Movement crashing (someone mentioned this in the other thread)... Any idea?

-Justin

gaekwad2

15th September 2003 19:08 UTC

How about making it work in HSV (as well as RGB)? Then it could be used to rotate colours.

Jaak

15th September 2003 20:06 UTC

that is good idea... tho' it would be slow

Deamon

15th September 2003 21:32 UTC

Maybe it's possible to have a selection box wether you want to use HSV or not, just like Rectangular coords in the DM. That would only cost speed if you really want to use HSV, not if you're only planning on using the RGB abilities.

sidd

15th September 2003 23:38 UTC

i doubt that it would make any different on speed whether you coded in the hsl-rgb convert, or avs had it done in the background. Its still the same algorithm.

Whats more.. if you want to edit according to hsl, and not just change them, you would need to first convery the three rgb tables into hue lum and sat. Then fuxr them around.. then change them back to rgb.

like rgb-hsl > (your code) > hsl-rgb

very fucking slow indeedy

sidd

16th September 2003 00:26 UTC

Wellll. heres a nice, but not very useful colormod thingo.

Uses the hsl-rgb alg. to make a neeto dynamic clear screen (ala shreyas' APE). Hue shifts on beat, and lum and sat are 'pumped' using smoothened out getspec stuff.

Because its not mapped to the original rgb values in any way, all the code is dont per frame, so its nice and speedy.

sidd

16th September 2003 00:54 UTC

XP
how silly ive been

Editing with hsl can be done very easily.
like i said before, you do

rgb-hsl (your code) hsl-rgb.

What i didnt think of was that the input rgb is 3 equal maps. Or other words, one greyscale map.
So the initial rgb-hsl alg. can be simplified to:

hue1=0; sat1=0; lum1=red;

as hue is unused, saturation is greyscale, and lum is the level (can be any of red green or blue).

the you can change around hsl all you like:
even do stuff like hue=sin(hue)+lum
Here's a nifty eg, its a bit slower.. but still ok.

Jaak

16th September 2003 05:09 UTC

Yea, the code is waay too big tho'

Zevensoft

16th September 2003 07:00 UTC

One main problem though is you CAN'T do HSL with a proper image, as you would need to pull data from other levels, like you can't use

red=(red+green+blue)/3;
blue=(red+green+blue)/3;
green=(red+green+blue)/3;

to make grayscale.

gaekwad2

16th September 2003 09:55 UTC

Ah, forget the whole idea. I now think it would be extreeemely slow. Sorry, I was thinking of Colorfade (which of course works differently).

Tuggummi

17th September 2003 07:29 UTC


red=(red+green+blue)/3;
blue=(red+green+blue)/3;
green=(red+green+blue)/3;

Hmm, haven't tested this myself, but what about if you save the variables first? like:


rgb=(red+green+blue)/3 ;
red=rgb ;
green=rgb ;
blue=rgb

Would that create a grayscale image?

gaekwad2

17th September 2003 09:14 UTC

No.

As explained above Cmod consists of 3 seperate maps for each channel. Therefore you can't mix colours with it.

Tuggummi

17th September 2003 09:17 UTC

Hmm... aah, yes. How stupid of me :hang: