Intel ( i845G ) profiling

[Simon Thum]

Matthias Hopf wrote:
> On Mar 12, 08 12:52:08 +0100, Simon Thum wrote:
>>> Well, I implemented this, so I know that it does arbitrary FIR
>>> filters. But maybe you know better from just reading the abstract...
>> Sorry I didn't mean to offend you. I made a guess which wasn't properly 
>> communicated.
>> I meant 'linear' as in gamma-corrected or 'linear with luminance'. This 
>> essentially means you need at least 10 bits of precision or tricky 
>> lookups (or accept loss). I don't say thats infeasible or you/the 
>> authors didn't do so, but usually this is mentioned. Though 
>> 'High-quality' could refer to that, I don't know.
> 
> Ok, that makes sense. So far all filters have only been described to
> work linearly in some color space (which typically R'G'B' is used, which
> doesn't have a linear mapping to linear RGB). Yes, this is some aspect
> many people do not understand or care.

That's exactly why it assumed it would be mentioned - because people 
usually don't.

> Question is: in which space do you want to be linear? Perceptually,
> R'G'B' is typically what you want, there are some exceptions, though
As I see it, it's the other way round: (beware of pet concern)
Stuff with photons and so happens in nature. Nature behaves as it does, 
not as we percieve. And as well not as our displays, which more or less 
coincidentially reflect some of the properties or our perception, model it.

This means typically you need a q-linear space. (q is quantity of 
photons involved. luminance is a well-known size to satisfy that.)

And 'typically you need' means 'whenever you add values' (or assume 
linearity by other means).

To make it short, the algorithm dictates the space. IMO one needs to 
justify staying in gammacoded space, not leaving it. That makes the 
coded case be the exception, and linear the rule. As cited:
http://www.w3.org/Graphics/Color/sRGB (at end of part 1)

> (e.g. antialiasing should be linear in RGB, thus modern cards do
> gamma-corrected antialiasing in R'G'B' AFAIK).
I hope so, otherwise it would be wrong.

> If you want to be linear in RGB with an arbitrary filter, ATM I don't
> see an alternative to the inverse-gamma, filter, gamma sequence - and
> there you certainly run into quantization issues. 10bit might help, but
> then you would like to have the better quantization anyway. This doesn't
> tell, however, whether the filter can be done on GPUs or not. Most
> probably, you can do it easily, and GPUs use IEEE floats internally for
> computation anyway.
The modern ones should easily cope with it, if one programs them so. 
Depending on what you do lookups might be a feasible alternative.

However the whole thing was a misunderstanding anyway, it just wanted to 
prevent rasterman from implementing a prefiltering step to a box filter 
because of false error attribution, which luckily wasn't the case.


Regards,

Simon