Fixed the layout for the Color Mix effect Blend Mode property. And added linear burn, pin light, linear light, and vivid light. Thanks again for all the feedbacks!!!

Adjusted the label to Blend Mode as Aaron Carlisle suggested.

Hi, original purpose of Blender was to produce images from 3D scene.
Historically, there was an audio sequencer decoupled from video sequencer. They were merged by 2.5 re-design.
If you take attention to Edit Strip panel in Metastrip properties, you can see that they are based on Scene, Movie, Image strips properties with a blend mode dedicated to image blending.

Hi guys,

I also prefer one "blend" effect. Regarding the compatibility issue, this should be fixable with versioning code that will automatically convert the old effect strip types to the new one.

IMO I think as Sergey and Aaron suggested , having one effect with multiple blend modes is much better. It use less space in menus for a similar effect.
Also, many people don't know each blend mode and what they do, so they like to test them one by one. It would be easier with only one strip.

Fixed a little bug in do_screen_effect.

Hi szap, thanks for the support! Blender is a great software, I believe that it deserves to have this basic blend modes in VSE. I work with video editing in my spare time and all other professional editing softwares have those, but I do like blender and decided to add them myself. I really hope it gets accepted!

Hello, I've used the VSE many times for doing color grading and finishing of animation done in blender, including many professional projects.
Having screen and overlay modes was simply my top secret feature request for the VSE , this is making some simple things possible like adding grain or light effect that don't blow out the image.
Other modes can be great to have but I think these ones are the most important missing ones.

I just updated the diff with changes concerning the code style and the 'BLI_math_color_blend.h' functions.

In D2872#67562, @Sergey Sharybin (sergey) wrote:

Is it really needed as two different effects? To me it seems more like a "blend" effect, which will support any of blending modes from BLI_math_color_blend.h. Even if we currently only will support two blend modes, still don't see why it's beneficial to have different effect type for those.

Is it really needed as two different effects? To me it seems more like a "blend" effect, which will support any of blending modes from BLI_math_color_blend.h. Even if we currently only will support two blend modes, still don't see why it's beneficial to have different effect type for those.

I removed the Eak define directives and replaced them for inline functions as requested, concerning the SET_TYPE indentation, they are as the other ones (gaussian blur and text are the ones that are off).

I tried to modify the code accordingly to the blender code style.

It is very important to follow the code style. I will read the link you sent and adjust the patch accordingly as soon as I get back from work.

I haven't tested the actual code yet, just glanced through it. There seem to be many cases where the Blender code style isn't used, which should be addressed. I haven't pointed out every single thing, but with my comments you should be able to fix them all.

Committed rBe9d06f086698049447fe004fec20d715b603a571

Not specific to this patch but I think that we should move all the color blending strips into one "blend strip" where the user can choose the blend mode of that effect strip.

That should be very nice, thanks a lot! I shall work on more effects in the future.

Didn't check details really, but seems like a reasonable set of changes from a quick glance. Added a single suggestion. Feel free to commit to master.

Looks good to me. If noone else has any objections, I can commit.

Hi, thanks for your review.

First: I think it is sensible to add those, since they are available as basic layer effects in Gimp/Photoshop too and have their places (provided, that you got your formulas right, though, haven't checked).

As @Joshua Leung (aligorith) mentions please use English, that being said, the video settings have changed a little bit in 2.79 as mentioned in the release notes

More than a week passed without a reply.

This issue was already fixed by 71f0c32dad8.

Alright. My bad. Wasn’t aware. I’ll see if I can come up with a patch or two to address the issues, though, because this is pretty important to me.

Thanks for the report, but it doesn't sound as a bug at all, more like a feature request or an enhancement request which we do not accept in the bug tracker. There are lots of areas in Blender which can behave better, but with are behaving fully according to the design and hence not considered a bug.

FYI: For now I’m preprocessing the input by converting to 24-bit RGB before importing into Blender, but that clearly isn’t enough most of the time. Even 8-bit (per channel) YUV can only be used with heavy dithering, and e. g. 10-bit input (which is getting increasingly common) loses way too much precision. Given FFmpeg’s rather awkward pixfmt support (owing to swscale legacy), it seems like using libzimg directly is the best option.