LUMIERA.clone/doc/devel/rfc/RenderOptimizer.txt
Ichthyostega b556d2b770 clean-up: comb through the historical pages to fix markup errors
Some sections of the Lumiera website document meeting minutes,
discussion protocols and design proposals from the early days
of the project; these pages were initially authored in the
»Moin Moin Wiki« operated by Cehteh on pipapo.org at that time;
this wiki backed the first publications of the »Cinelerra-3«
initiative, which turned into the Lumiera project eventually.

Some years later, those pages were transliterated into Asciidoc
semi-automatically, resulting in a lot of broken markup and links.
This is a long standing maintenance problem problem plaguing the
Lumiera website, since those breakages cause a lot of warnings
and flood the logs of any linkchecker run.
2025-09-21 05:40:15 +02:00

68 lines
2.2 KiB
Text

[options="autowidth"]
|====================================
|*State* | _Parked_
|*Date* | _2007-06-07_
|*Proposed by* | ct
|====================================
Render Optimizer
----------------
Render only parts of a frame which are necessary for the Output;
optimize render pipeline for efficiency
Description
~~~~~~~~~~~
This Idea is just stored here for later reference/implementation.
Effects give some information on which data their output depends (like
transitions, temporal dependencies, color/alpha etc) and what the operation
costs. Based on this information we optimize the render pipeline, for example
if the output is a zoom, then we only need to calculate the parts of a frame
which will be viewable in the output (plus some more dependencies, like blur
has radius and so on). Further in some cases it might be favorable to reorder
some effects for the actual render process, as long it would produce the same
output as the original sequence of effects.
Comments
--------
Possible classification for video filters:
1. The filter only changes the color of each pixel in the same way
2. The filter deforms the image but leaves the color
3. The filter makes complex things. The only additional hint it can export is
the number of referenced past frames, if such a limit exists (sometimes it
doesn't).
Filters of type 1 and type 2 never use any previous frames, and are strictly
one frame in -- one frame out. Filters of type 1 can always be swapped with
filters of type 2, the output is the same. All other filters cannot be swapped
in general.
The good news is, that:
1. All commonly used filters are either type 1 or type 2
(type 3 are more the fun effects)
2. Filters of type 2 are colormodel agnostic
3. If a filter of type 1 makes only linear transformations of the color vectors +
(i.e.: new_color ≔ matrix · old_color),
then the matrix can be transformed from e.g. RGB to YUV, so these filters can
always work in both colorspaces directly
Parked
~~~~~~
Generally this is accepted but needs some more polishing when we go over it.
Christian Thaeter:: 'Thu 14 Apr 2011 03:06:42 CEST'
''''
Back to link:/x/DesignProcess.html[Lumiera Design Process overview]