Re: [CinCV] Color handling
Any reason for not using 8/16/32 bit as a fraction (0-1)? So 8 bit would have a resolution of 1/255, 16 bit of 1/65535 etc. All operations can be done with 4 byte integer math. 16 bits linear will be barely enough to capture an 8 bit nonlinear space, and that's leaving out head- and toe-room. So we're at 32 bit already. On top of that, we'll need much deeper resolution to avoid substantial quantization errors moving to/from the PCM space. This will possibly be pushing the limits of 32 bits, especially for high dynamic range spaces. Then we have to worry about overflow/underflow/saturation and 64-bit multiplies (32 bit builds will need custom intrinsics). Part of my impetus for suggesting float was avoiding any unnecessary cleverness. Multiplying cannot cause overflows this way. Easy resolution change, too. I don't see how that's different from float. Lookup-tables can be used if necessary - a near impossibility with floats. This is a point... but I _am_ using lookup tables in my float code. There may be a better choice than modff, but it works, and I don't think it's even close to a bottleneck (I'd expect it to be memory fetch). Possibly great speadups as integer ops can be executed in parallel, either in the CPU or the GPU. I'm used to the CPU's FPU being more powerful in general than the ALU these days. I'm also concerned that premature optimization where everything has to be SIMD out of the box just means the code never gets written, or never fully debugged (the existing Cinelerra colorspace code isn't even SIMD, but it is horrbily buggy). I curse many many things about Cinelerra... the pipeline speed isn't actually one of them. Just an idea. Sure :-) And I think you're right in the tactical sense... but overall I think float is a more practical idea. It will be slower in the ideal case, but I don't think we'll ever be within spitting distance of ideal speed. Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color handling
Just an idea. Sure :-) And I think you're right in the tactical sense... but overall I think float is a more practical idea. It will be slower in the ideal case, but I don't think we'll ever be within spitting distance of ideal speed. BTW, if I sounded ungrateful for the comment, I didn't mean to be. I was hoping for this kind of challenge to my specific proposal points on the theory that if I can't defend then, I shouldn't be implementing them. Hermanr already scored a direct hit :-) Monty ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
RE: [CinCV] Cinelerra vs Cinelerra-CV
Ciao! I finally migrated cinelerra's builds to use the new name cinelerra-cv. Thank you so much! :-) Raffaella, would you please add a line in the webpage stating how to install cinelerra, once the the PPA has been enabled? Sure. Sorry for the delay. Somehow I messed up my git push ability to update the Cin site. I have to fix that first. Ciao Raffaella ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color handling
På Mon, 05 Nov 2012 14:27:02 +0100, skrev Monty Montgomery xiphm...@gmail.com: ... and presenting 0.0 as black and 1.0 as white internally is totally out of the question? No. :-) However, if black is 0.0, then super black would be negative, and hilarity ensues. So we have to make up our minds about what headroom and toeroom are for, how to use them, and how to represent them. With your proposed studio swing mapping most compositing and filtering operations have to scale and bias to work right. E.g. black + black + black will be a shade of gray, unless a bias is subtracted. Yup. I was suggesting it as something of a path of least resistance. For the record, we already have this problem with studio swing. After some reconsideration, I realised that the kind of black we are talking about here is black level black. Not the matemathical black hole kind of black. The black level isn't zero luma. It is below perceptible luma. And if you add three just below perceptible lights, you DO get something brighter than pitch black. This may or may not be what you want. My point is that the accumulation of noise or fog when you add several black level signals is the most faithful representation. Because unless they are synthetical, they will not be crushed/clipped blacks, but a noise floor. -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
Re: [CinCV] Color handling
På Mon, 05 Nov 2012 14:27:02 +0100, skrev Monty Montgomery xiphm...@gmail.com: ... and presenting 0.0 as black and 1.0 as white internally is totally out of the question? No. :-) There is more. I can't see we have adressed what kind of black and what kind of white. * Aquisition medium black and white ? (e.g. from max density in the film emulsion to a clear base) * Display black and white ? (e.g. the monitor's brightness range) * Scene referred ? (From black hole to supernova, if you have bits to burn.) HDR computer graphics can be scene referred, and film scans will likely be media referred. They can be easily represented in full range inside the program, but at display time they have to be remapped to a range that the screen can manage. This remapping is typically lossy, often very much so. You don't want to do it at import time. Well, for some workflows you DO want that. But not as the default, right? This is getting hairy. Should Cinelerra have two modes or workflows; one for conformed video editing, and one for high tonal fidelity grading and compositing? -- Herman Robak ___ Cinelerra mailing list Cinelerra@skolelinux.no https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
