Hello,

Yes, I'm fully aware of the advantages of running the whole machinery with virtually no quantization errors. I was under the impression that this was a feature which never became supported.


Since you obviously had a version with float supported, maybe the question is what is different with the version that doesn't. If you have the sources for both, and they're fairly close in their release time, maybe some diff -r could reveal the issue (or am I too optimistic?).


   Eli


Tony Hardie-Bick wrote:

Hi Eli,

When I had RGB-FLOAT working, I was doing a lot of colour distortion, and this setting gave a much finer level of detail under these conditions.

This is because when you stack a number of RGB-processing filters of limited precision, each one quantises its results to the colour precision, and this loss of precision, in the integer (especially 8-bit) case, becomes visible when a filter at the end of the chain tries to expand a difference between, say, a value of 100 and 101 to 100 and 110. In the integer case, clearly you get a sudden step from 100 to 110. In the floating point case, you get the full gradation returned, even though the final output may still be quantised to 8-bits (per colour).

So I miss this, as I was doing a lot of colour distortion again.

Tony




--
Web: http://www.billauer.co.il


_______________________________________________
Cinelerra mailing list
[email protected]
https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra

Reply via email to