> Negatives need to be scan on 10 or 16 bits /pixels and no gamma. RGB 8 bits > is just not enough. > Of course not everyone has a HP 10 bits screen to grade negs.
Did you mean 'no gamma correction' or did you really mean full-linear? Ahh, right, if it's a negative, you don't want to apply a positive gamma.... > As far as I can see (maybe not far enough :-) ) Bt601 it's almost an > obsolete gamut, ideally a RGB float to Bt 709 with grading in between would > be fantastic; bt.601 is still my most common target, though I consume and produce plenty of bt709 as well. I wasn't actually suggesting using either; I was suggesting an RGB space with a known curve (so that the 601 and 709 matricies were irrelevant). Possibly even a linear-light RGB space for the pipeline-- that may be more trouble than it would be worth, though it would be worth something. The real rub in all of this, and the impetus for getting me thinking to start with, is filter operations using colorspaces with singularities at black (like HSV). When you don't know where black is, any HSV operations are wrong at best and useless at worst. Gamma manipulation is also completely wrong when you don't know your black and white points. I don't do any film at all, so that's part of why I was asking :-) Given that it sounds like digital cinema has all gone to log curves, if I'm going to use an assumed pipeline space, it sounds like it has to be linear light :-( ...how do log colorspaces handle color mixing? Same way as it would be done in the exponential space (mix the RGB components without conversion because it's 'close enough')? > e.g. can one modify the export through y4mpeg pipe ? ffmpeg > can han handle the color matric and other LUTs now as well as a temporal > denoiser !!! Yes, part of the plan would be the inputs and outputs both become smart. Is yuv4meg2 actually extended to include colorspace information now? I'd have expected it to be 'hardwired' to bt601 given that it was intended for MPEG2 interchange (not that it would actually enforce anything. I stick 709 in it all the time myself). That had been part of why I extended it to Y4O for ogg tools; so I could include siting, colorspace... and audio! :-) > Of course it takes a hell of a time and you can't expect an automatic > plugin. It has to be done manually. Yes. The idea is not to make grading automatic; that's impossible. The idea is to begin grading at a more sensible starting place, one that's perhaps even good enough that a n00b who knows nothing gets OK results while ignoring it all. There are places where Cinelerra can be making colorspace management easier without taking any options away. Right now, simple operations take hundreds of clicks. Having to set everything explicitly/manually every time is a guarantee of a large number of mistakes. I was, conceptually, suggesting several separate things that are all part of the same big job: 1) Do away with the 30-odd different internal pipeline formats. It's just silly. Even HV has done this, though he kept both RGBA-float and YUVA-float. I don't see the reason to keep 2; unclipped RGBA-float <-> YUVA-float is a lossless transformation (once chroma is reupsampled, but then the current editor already does that). 2) Also making the pipeline a single assumed internal colorspace. It could be linear, log, gamma, whatever; we're in float, they're all equivalent. The rub here would be conversions; in some ways choosing linear is the most extreme choice because it means lots of reconversion (lossless reconversion, but burned CPU nonetheless). Perhaps the better idea is to be able to choose the pipeline working colorspace, the way we currently choose the pipeline pixelformat. 3) Compositor window and display in general needs to be smarter about displaying colorspaces, like, it needs to be aware they even exist. Right now it just ignores the problem entirely, so you get to see everything as if it's sRGB which is just maddening. Or is there a setting somewhere I've been missing for years? 4) If the colorspace code is being tweaked, then we might as well tackle the chroma siting problem at the same time. This, at least, can be hidden from the user, because the pipeline will still be in 4:4:4, the conversions at import and export time just need to be correct (which they currently aren't). However, I'd not want to attack this problem without 1); too much code. All of the above are independent proposals, they're just on the same topic. Like, 3 and 4 could be done without 1 and 2... 2 is certainly more wishful thinking aloud right now than the others. Monty _______________________________________________ Cinelerra mailing list [email protected] https://init.linpro.no/mailman/skolelinux.no/listinfo/cinelerra
