Maes
Here's an old post I made on the subject,
Posts: 14743
Registered: 0706 
tempun said:
Why? I think that's correct. It's meant as an aftereffect, so you need to calculate the resultant color with usual palette and then apply the green tint.
Not if we're talking precalc indexed (paletted) tables here. Color index #X and #Y may give color index #Z for palette 0, but may give a completely different color for a greentinted palette (which is, for all effects and purposes, a different palette). Imagine the above scenario with one of the almost allred pain palettes ;)
Of course, if we are talking about full colorspace processing and accepting any resulting overheads as inevitable, the above point is moot, like most of the indexed limitations.
tempun said:
That's what the ports are doing.the naive colormatching algorithm is slow yes, but I think table generation can be sped up to O(n^(2+eps)).
Well, the O(n^2) part will still be dominant for a table of rank n, no matter how quickly you can produce the matching for any two given colors, even if it's O(1) per pair.
Wagi said:
I think you misunderstood what I said. I'm not talking about an 8bit TRANMAP. I'm talking about a lookup table that can, with perfect accuracy, be used to assist color calculations in an RGBA colorspace. As long as each channel (red, green, blue, alpha) each have one byte dedicated to them, it will work, and quickly (at least quickly for something that's not hardware accelerated). You're right, though, in that such a lookup table would be useless in a HSV colorspace.
Hmm....that's actually a good workaround at least for the RGB color space, but only if the three color channels are really truly independent. E.g. in the case of simple average transparency T between two pixels X and Y, akin to what TRANMAP is doing, you could say that e.g. the Red transparency pixel only depends on the Red pixel of X and the Red pixel of Y or Tr~XrYr, therefore you could build a LUT only for the red channel, and so on for the others. So a "truecolour transparency LUT" that performs accurate RGB truecolour average would "only" require 3x64K tables, which is indeed not bad considering that with a single 64K table you only cover the indexed case of a specific palette.
The problems start if you start considering effects where e.g. Tr is NOT independent of Xg, Xb, Yg and Yb. In that case, you will need 9 such tables (every possible combination of e.g. Xi*Yj where i,j={r,g,b} plus an additional weight matrix.
The simple transparency table can be thought of as a special case where only the cases Xi*Yj with i==j are retained (diagonal system), and where the weights matrix is unitary.
Edit: heh I was about to draw some matrices and formulas here, but nm ;)
LUTs are OK if the effects you are using them for are between completely orthogonal channels. However, if you tried to make an effect that's based on the values of all three channels with RGB LUTs (e.g. their overall luminosity), then you'd be in deep shit, and need to use a heavyweight full 3x3 system of matrices plus weights.
However, you could construct a lightweight "sparse" system using similar tables for HSV, where it would be easier to implements certain effects like global hue or luminosity shifts. OTOH, transparency would be awkward in such a color system.
Heh Doom: Photoshop D.I.P. edition? ;)
Last edited by Maes on Oct 11 2011 at 21:37
