I recently tried to edit videos which where recorded in the Panasonic VLog format in the video editor. Using the ACES configuration for OCIO it is actually really easy to get good looking colors by just selecting the right IDT for the footage. But I recognized that it is nearly impossible (for me at least) to color correct this footage using the color balance modifier with the Lift/Gamma/Gain controls. So I started implementing some Offset/Power/Slope controls similar to the ones from the compositor which should work better for a scene referred workflow. At the moment this is still work in progress, but you can take a look at the current state here:
Great idea. I hadn’t even realized this was missing from the VSE modifiers. If it works the same as it does in the compositor, I think it will be perfect.
Imo, this should be a very welcome enhancement of color grading in the vse. My guess is that if you keep the functionality in consistency with the node everything should go easier in the review process.
I added a .diff extension to your github link and was able to apply the patch.
There seems to be a small difference in the aligning compared to L, G, G:
Unfortunately I don’t see any changes in the preview when changing values in O, P, S, and noticed that the patch is 6 days old. Is there a newer version of the patch?
Ah, the reason for this is that sRGB is not working with O/P/S. If it is not supposed to work with it, there should be some information in the statusbar, when switching to it. Alternatively could the O/P/S button be disabled when Color Management > Sequencer is set to sRGB.
Yes, that was my plan. Implementation and also UI should be the same just the mathematical operation then is different depending on the selected method.
I guess that’s because the “Invert” buttons are currently not there. I will add them. Then it should behave the same way.
You might have used a source with an integer pixel format. Up to now I had just implemented that for a float pixel format to try it out. I will add that later. But I guess if you set up an OCIO configuration, any source will be converted to float anyhow - in case you want to try it out.
Up to know I didn’t compare it in detail to the implementation of the compositor, but that’s a good point. It’s a pity that the compositor and the video editor do not share code.
Yes, if I did it right, it should be an implementation of the ASC-CDL color correction method.
From how I understand it, if you have set up OpenColorIO and select the right input color transform for the video strip, it should convert the source material to the linear working color space (ACEScg or ACEScc for example). And there the color balance modifier is applied. For output on the screen and for rendered output the result is then converted to the viewing color space e.g. sRGB.
But I am no expert on how color is handled in Blender, so please correct me if I’m wrong.
@JosefR You should reach out to @iss on blender.chat or you could PM him there. He’s the BF dev working on the VSE and can let you know if this enhancement is welcome or not.
That is correct, when you set color profile for strip, it converts image to float if needed and applies the profile to convert footage to scene reffered linear space. I would have to double check if float conversion happens automatically or only when requested explicitly.
Having said that, I saw, that you imported footage as movie strip. Currently we only import movies with 8 bit color depth. Last time I wanted to implement support for this, I think issue was that FFmpeg libraries are not compiled with higher bit depth support.
Yes, there is some code that is technically duplicated in compositor or sequencer. If compositor code is usable for VSE, it could be included in library (see BLI_math_color.h) and shared between both modules.
I think that patch looks reasonable even if code can’t be shared.
I didn’t know this. Any chance to see this fixed in the future? I guess using an image sequence is not really an alternative due to file sizes (at least for 4k footage).
OK, then I will continue the way I started and will send the patch when I think it is done. It should anyway be better to keep the change consistent and not try to rework some code at the same time.
I may be incorrect on this topic, but from what I read this is bit more complicated by fact, that libx264 can be compiled with say 10-bit support, but then it will be able to decode and encode only 10-bit footage, at least that’s how I understand it.
So it’s not (only) FFmpeg that is configured this way. From what I read libx265 can decode and encode various bit depths. Perhaps other codecs too. I would have to do more research to see if and how this is possible to implement.
Didn’t quickly see any specific flags on ffmpeg to enable/disable 10 bit support, but x264 is build with the default settings which enables both 8 and 10 bit support
I will have to re-check this it was long time ago I was looking into this. I remember, that I was getting no image, but I didn’t check decoded buffer directly to see where the issue is.
@JosefR How are things going with your patch? I think the curfew for getting new features in 3.0 is the 22, so you might consider submitting your patch as soon as possible.
Great. Maybe the description could need a bit more information on how to use it? Like how to get all of the color space options? Why is it necessary to uncheck proxies? Does the button have any effect if ex. proxies are on and the color spaces are not set up like you do?
I disabled proxies because I got heavy color banding when using it. I guess the proxies convert the 10-bit DNx source footage to 8-bit. But in general, some lines about how to use it is a good idea, this would be needed for the documentation anyway.
