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