Can not confirm this.

Seems good to me

In T65724#700094, @Nathan Lovato (gdquest) wrote:

Are new tools or ops written in Python welcome in the Sequencer project?

Of course!

I'm surprised there is interest to rewrite operators in Python.

In earlier attempt there was some criticism, that for example we are trying to implement multiple cut operators, that each do something just a bit different.

I see several good reasons, why you would want to use scene linear colorspace in sequencer. Apart from working with scene strips, and HDR footage, overall integration with "proper" workflows and pipelines would be nice to have or being capable of.

I am OK with cosmetic changes not affecting functionality (not my job anyway :).

In T65845#701847, @Peter Fog (tintwotin) wrote:

If the hidden elements(many different strip types and their options) all should be visible, but greyed out, it would be overkill. As it is now with a submenu changing contents depending on the current active strip will mean less clutter IMO, however image and sound strips does not have a sub-menu, because there are too few entries.

In T65724#699723, @Campbell Barton (campbellbarton) wrote:

• Moving images_separate to an API call then adding the operator from Python seems like a token. All the Python operator will do is call the C API code which will have all the logic. How is this an improvement?

@Christopher Anderssarian (Christopher_Anderssarian)
I would agree with :FFF format for frame regardless of framerate. Each time I look at strip length now, I have to think about the format. But according to https://en.wikipedia.org/wiki/SMPTE_timecode, the format is HH:MM:SS:FF, which we are violating already.

@Jeroen Bakker (jbakker)
Thanks for reminding me of halide - forgot about that one.

Is this new issue?
I mean it should be easy to fix, but not sure if I should look for what caused this.

It is true that this is not bug.
Will create TODO for this.

This is untested update.

Oops this didn't worked as expected

Thanks, for explanation.

Today I also noticed this. Got patch ready.

I guess high prio for this.

In T65271#691416, @Brecht Van Lommel (brecht) wrote:

The reason the sequencer color space was added at some point, was to allow using scene linear colors while still giving backwards compatibility for sRGB

Closing this again.

Fixed in aa003c73245f

@Louigi Verona (LouigiVerona) Sorry for misunderstanding.
While it's true, that I constantly overlook details, but still sometimes, less is more(description is quite verbose).

I am once again looking at this task, and see, that the sample video has variable frame rate.

In T65458#694999, @William Reynish (billreynish) wrote:

We should probably just copy what we did for text objects here.

Closed by 58bea005c58956674c7f4a9a7a85ff943c140f03

Closed by fd51d2f97cbe0117e8939396f196366a0043849e

Closed by 1fd7b380f4cf8a0489b405de2819f228a4da5ea2

Overhead is caused by image scaling in preprocessing stage. Linear interpolation is used, when render anti-aliasing is used in workbench settings, even if render engine is not set to workbench.

I remember this working in 2.79.

In T64565#692683, @Brecht Van Lommel (brecht) wrote:

We still have to bring box selection for graph/dopesheet/NLA editors as well, they have the same issue.
For markers, what I meant is that sequencer_box_select_invoke should also check if the mouse is over any markers before allowing box select to start, to be sure it's really over empty space.

• remove unintended changes

In D2504#113929, @Brecht Van Lommel (brecht) wrote:

Ok, I guess this is correct then. Still think it would be a little better to deduplicate logic here.

In rB7ccc7ef61fde38e517d730cef05242cc150126d1#234202, @Campbell Barton (campbellbarton) wrote:

I'm not sure what purpose do_versions_seq_alloc_transform_and_crop serves now, can't it be removed?

Thx guys for help here!