POV-Ray : Newsgroups : povray.binaries.images : Inversion : Re: Inversion Server Time
19 May 2024 04:22:22 EDT (-0400)
  Re: Inversion  
From: Anthony D  Baye
Date: 10 Apr 2016 21:15:01
Message: <web.570af99bc6ebc480fd6b6fe10@news.povray.org>
clipka <ano### [at] anonymousorg> wrote:
> 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:
>
<snip>
>
> 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.

In the spirit of foresightedness... I'm going to shill for my idea of a plugin
api again.  Because:

1) New functionality should be added by new code, not modification of old,
working code.

2) Adding a plugin to a directory and using dependency injection would be vastly
preferable to recompiling multiple un-official versions.

In fact, I would imagine that large parts of the current codebase could be
abstracted out as plugins (necessary core plugins, perhaps, but plugins)

I would also imagine that this would be a task of more than somewhat Herculean
porportions, so I completely understand resistance.

Unfortunately, I wouldn't know where to begin with such a thing, as I have a
hard time following the patterns in the codebase. (to put it lightly)

*kicks the hornet nest and hides*

Regards,
A.D.B.


Post a reply to this message

Copyright 2003-2023 Persistence of Vision Raytracer Pty. Ltd.