Cutting to the chase, A Proposal: Implementing only a single color format for the CinCV pipeline, and making it studio-swing RGBA float. Input and output would rely on this assumption and handle conversion to/from sRGB/JPEG/bt601/bt709 spaces automatically. Along with that 'fixing the compositor so that it actually displays studio swing properly'. Chroma subsampling can be handled similarly to how it's done now, but adding non-JPEG sitings (again, a concern for import/export only).
I can see that there used to be a need for brutally efficient pipelines back in the late 90s. Unfortunately, that came at the expense of maintainable code or the user being able to manage the complexity effectively. Everything we're doing now, we can do in RGBA-float, and do it without any ambiguity. Today's FPUs are going to be more powerful overall than ALUs. Additionally, I suggest that anyone managing pipeline color carefully in CV is using RGBA-float with studio-swing levels already, so this will be both path of least resistance and path of least surprise. People have asked for YUVA-float (HV now has it apparently), but the mapping between the two is lossless and RGBA is more useful for perceptual operations. Note that although I'm suggesting a mandatory RGBA space, I'm also suggesting standard studio-swing levels (16-240 with head/toeroom). Full-swing imports will be mapped to the restricted range. This is not quite as radical a suggestion as it might seem; the file handlers will need some new code (calling some new, centralized colorspace conversion code that is aware of the spaces). The pipeline mostly sees code removed, and the plugins also only see code disappear not appear. Leaving aside the effect on existing projects-- what am I missing? Monty _______________________________________________ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
