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.
68 lines
2.2 KiB
Text
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]
|