I would propose to have list of proxy sizes in preferences for automatic setup (100% selected by default) and no automatic building for different sizes in runtime. No changes to manual proxy setup are needed for this change.

I'm a bit confused with this statement in the context of "Always use automatic rendersize". Can you explain a bit better what would be artists workflow with your proposal?

In D11336#292627, @Sergey Sharybin (sergey) wrote:

I would propose to have list of proxy sizes in preferences for automatic setup (100% selected by default) and no automatic building for different sizes in runtime. No changes to manual proxy setup are needed for this change.

I'm a bit confused with this statement in the context of "Always use automatic rendersize". Can you explain a bit better what would be artists workflow with your proposal?

This would mean that preview size in sequencer would be always defined by it's size on screen in pixels and there will be no options to choose fixed size as it is now (25% - 100%)

This would mean that preview size in sequencer would be always defined by it's size on screen in pixels and there will be no options to choose fixed size as it is now (25% - 100%)

That is how I was imagining it to be :)

Are there other aspects of the design I can help with?

In D11336#292682, @Sergey Sharybin (sergey) wrote:

Are there other aspects of the design I can help with?

I think I can use some help to make sense of this overall, because as I outlined in description, current design is not immediatelly compatible with this change.

To summarize it :

• User won't know in what size he will be working in, so he can't really configure proxy sizes optimally. You can still have list of sizes in preferences, but it is very likely you want to use just one.
• Suggested downscaling of movies as done in D9414: VSE: Render in size nearest to preview image could be improved if also upscaling was supported. Would that be OK? Originally I wanted to implement scaling to nearest possible size even if factor wasn't power of 2, perhaps this would clean up API a bit instead of having to initialize 10 sws_scale contexts, have one flexible?

To expand a bit on problem 1:

• Say you have 4K video and you use 25% proxy sizes.
• Now you have 960x540 clip you need to composite in. You don't want to use 25% proxy, because image will be awful. So you would like to use 100% proxy.

Should there be a way to manually configure proxies per strip?

Alternative could be proxies with uniform resolution (absolute size). This would guarantee you same performance across all media, but there are other design issues with that like how to tell what was resolution of original media.
Benefit is only ease of configuration and no need for code selecting best media according to current preview size. So not sure if this is something you would consider doing.

For the per-strip configuration: I do not see why it is needed. If the sequencer performance is good, I would not expect users to think about proxy sizes.
For the upscaling my concern is that it is more lossy.
For the power of two the idea was that it is easier to implement and optimize using SMID.

Unfortunately, didn't have time to finalize things on a more of design level here.

In D11336#301824, @Sergey Sharybin (sergey) wrote:

For the per-strip configuration: I do not see why it is needed. If the sequencer performance is good, I would not expect users to think about proxy sizes.

Would you suggest then to support only 100% proxy size? that would probably simplify things.

For the upscaling my concern is that it is more lossy.

Ok, makes sense.

For the power of two the idea was that it is easier to implement and optimize using SMID.

I have 2 points here:

• Not sure if sws_scale does use more optimized path when scaling by power of 2, I will have to check this. Then you will have to scale this image again in sequencer to expected size (+ other transforms compounded).
• In D9414 I have outlined problem of rendering image strip - All information sequencer have is "I need to render D:\image.png". What downscale to use?

If you had API where you provide size you want to get, sws_scale can do whole job and image rendering can use power of 2 transform followed by slower method, but on smaller image. Downside is relaying back information about original size.

I would suggest to do:

• Have API like IMB_anim_absolute_near_size(..., size_x, size_y) and IMB_loadiffname_near_size(..., size_x, size_y)
• Use only power of 2 scaling
• Store used IMB_DOWNSCALE in ImBuf
• Rest processing do in sequencer

I can also check how bad impact would have using exclusively 100% proxy.

Unfortunately, didn't have time to finalize things on a more of design level here.

Sure, I understand that this isn't #1 priority.

Would you suggest then to support only 100% proxy size? that would probably simplify things.

Not really what I suggest. What I suggest is to remove configuration burden from users, but still investigate the closest proxy size generation for improved performance/memory usage.
If the proxy file can be scaled down at real-time, then we can indeed only store 100% proxies on disk. But it doesn't really sound salable to me.

For the sws_scale and image sequences story -- I am not really sure why we treat image sequences different from video. You should be able to treat image sequences in the similar manner for proxies, giving similar performance and memory improvements.

In D11336#302136, @Sergey Sharybin (sergey) wrote:

Would you suggest then to support only 100% proxy size? that would probably simplify things.

Not really what I suggest. What I suggest is to remove configuration burden from users, but still investigate the closest proxy size generation for improved performance/memory usage.

Ok, What I can do is to get size of viewport (preview resolution at 1:1 scale) and consider this as baseline. Then build proxy that is closest to this resolution.
When viewport size changes, trigger build job to build new sizes if necessary.
Finally use size that is closest to real preview resolution (consider zoom level too).

For the sws_scale and image sequences story -- I am not really sure why we treat image sequences different from video. You should be able to treat image sequences in the similar manner for proxies, giving similar performance and memory improvements.

Because for movies we keep file open, so it can't be removed or changed. So you can read properties like resolution once and rely on it.
Each image is opened on demand and you don't know what you will get in advance.