Am 09.04.2016 um 22:32 schrieb Bald Eagle:
> clipka <ano### [at] anonymousorg> wrote:

>> What this new incarnation will add is the ability to apply different
>> tonemapping functions to each colour channel, perform cross-channel
>> colour maths, and as an extra bonus even use functions that depend on
>> the screen location.
> 
> So, this would be analogous to various image processing features and "filters"
> that a lot of graphics programs have?
> I find the screen location feature interesting, and am wondering how that will
> function, and what inspired its development.

"Because we can".

Actually the chain of thought was something like this:

(1) "To really wrap up the topic I want to provide the user with a means
to effect gamma adjustment for purely artistic purposes, so that they'll
never again have to misuse any of the gamma handling stuff intended for
purely technical purposes. Some global 'artistic_gamma' setting might do
the job."

(2) "Then again, artistic gamma adjustment is just a special case of
tonemapping, and possibly not even the best choice for what the users
actually want to achieve with it, so a dedicated 'artistic_gamma'
feature would be pretty short-sighted, wouldn't it? Better implement a
generic tonemapping feature."

(3) "Thinking about it, we do have this plan to add a generic full-image
postprocessing feature somwehere further down the road, which would make
this dedicated tonemapping feature obsolete. It would be wise to plan
ahead now, lay out the syntax we'll want for that future feature, and
already implement whatever subset we can, most notably tonemapping; of
course we can also throw in some other goodies like doing fancy stuff
based on the screen coordinates."

(4) "The full-image postprocessing feature will need to run after the
entire image has been raytraced, but the current architecture provides
no clean place to hook it up there. Let's see where I can hook it up for
now... ah, there's a nice place for it."

(5) "Damn, I forgot about anti-aliasing: It'll make a difference whether
we apply tonemapping before or after that step. The final full-image
postprocessing feature will inevitably need to operate
post-anti-aliasing, but the preliminary place I've chosen is
pre-anti-aliasing, so we're guaranteed to break the behaviour as soon as
we move it to its final place. I need to put it someplace else already."

(6) "Wait, hold it -- I think doing the tonemapping _before_ the
anti-aliasing actually looked better. So we probably need a switdh to
choose whether to apply it before or after anti-aliasing... then again,
in pre-anti-aliasing mode we'd have only limited functionality; and some
poeple might want to use both pre- _and_ post-anti-aliasing
postprocessing... Dang, this gets more complicated than I expected."

(7) "You know what? Sod it! I'll just name the pre-anti-aliasing
tampering with image data 'tonemapping', and the post-anti-aliasing
tampering will be called 'postprocessing'."

(8) "Hm, what about the non-tonemapping stuff like the screen location?
Ah, I'll just keep it in there. It doesn't hurt, and someone might find
it useful for something some day."

And that's how the screen coordinates have ended up in the tonemapping
feature.


> I would imagine that various functions could be used to adjust brightness and
> colour using gradients, concentric-type adjustment such as the cos^4 brightness
> dropoff typically seen in camera lenses, etc.
> I guess you could also use one image to map/adjust tones onto/in another kind of
> like a pigment/texture/image map.

With the x and y screen coordinates available, it should be possible to
write tonemapping functions that overlay a pattern onto the image (via a
pattern function); such a pattern could in turn be arbitrarily complex,
from a simple spherical pattern creating a vignette effect to a complex
object pattern based on one or more text objects overlaying textual
information like a singature or frame number.

Post a reply to this message