Hi all

Thanks for the comments, this is a very interesting discussion. In the
mean time I've make some modification to the blur plugin so that if your
color model is YUV, it coverts YVU to RBG before running the blur engine
and then convert RGB to YUV the output frame. I used the YUV plugin as a
basis for the conversion algorithm because YUV does the conversion
(start at line 320 of yuv.C, conversion is performed by the functions in
plugincolors in plugins/colors). As of now I still have issues with the
float RGBA color space, but I hope that I'll be able to fix this.
I was also wandering how I can share this plugin modification so that it
can be commented/further modified.

I understand that converting from one color space to an other and back
is lossy, but it seems that it provides more benefit to the user in that
the response of the plugin is more predictable and consistent. Are there
any way the qualify this lossyness other than use our eyes? Or what
about the multiple conversions from the codec that the media was
recorded in to the intermediate formate, to the internal format that
Cinelerra uses, to the change of color space in Cinelerra for the
plugins, to the output formats, to the final codec in which the edited
fromat will be played in? Is there any way to quantitize that? In the
end the color of each pixel is a matter of personal taste and can be
adjusted. However, blockiness, artifacts, or aliasing are more
problematic features if found in the final renders, but they are not the
effect of a change in the color space? or are they?

Félix-A.  


 

Le dimanche 22 janvier 2012 à 13:15 +0100, Herman Robak a écrit :
> På Sun, 22 Jan 2012 11:02:35 +0100, skrev Michal Fapso 
> <michal.fa...@gmail.com>:
> 
> > Thanks for your comments, Hermann.
> >
> > It seems to me that using only float RGBA color model would be quite a
> > good solution. Plugins would become simpler and should behave
> > coherently for any videos and precision should be also fine.
> 
> Indeed.  However, Float RGBA is buggy, at least in my builds.
> I can import Float formats like OpenEXR, and do HDR colour correction
> on them in Cinelerra.  But 8-bit images and videos come out black as
> soon as I apply any effect or adjustment.  I have not figured out why
> yet.
> 
> 
> > The drawback I see here is that float would require 4-times morememory than 
> > "YUVA 8 bits per channel". Also computation would beprobably slower for 
> > floats.
> 
> And all this extra precision is applied to the same old coarse
> 8-bit gamma-encoded data, without any prior smoothing.  Same with
> the half-resolution colour data, which _could_ have been processed
> as separate image "planes", halving the number of pixels per frame.
> 
> Naïvely upscaled images introduce false information, like aliasing,
> banding, artificial noise.  High-precision effects need pristine
> input to work well.  Either untransformed pixel data, or very well
> filtered and precisely transformed data.  The latter is expensive
> (slow!)
> 



_______________________________________________
Cinelerra mailing list
Cinelerra@skolelinux.no
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to