Will try to find more reliable repo steps as @Richard Antalik (ISS) and I could not reproduce consistently...

In T74041#877400, @Peter Fog (tintwotin) wrote:

It should only be in the Sequencer Preview Sidebar Tab called View - as it is only printing data in the preview and is executed when the playhead moves.

"View" could be good, yes (if it would really work to get the metadata from the preview...)

It should only be in the Sequencer Preview Sidebar Tab called View - as it is only printing data in the preview. AFAIR it only works for Blender generated EXR files, saved with that meta data inserted. There was the same problem in the Sequencer/timeline sidebar and it was fixed by Sebastian(?), but I can't find the commit.

OK, I am not sure how this would ever work in the Video Sequencer if we try to get the ImBuf from sequencer_ibuf_get (as this gets rendered and there is no metadata on the newly rendered ImBuf)...

• Regarding the panel being everywhere in the VSE: not so very sure anymore about putting it in the "Strip" tab, this will not display info for the selected strip, but for what you see in the preview (ImBuf)... so maybe makes sense to have it in all tabs?

Or put it in its own "Metadata" tab?

• Regarding the Panel actually being empty: seems like we are not displaying the original ImBuf, but the cache or something? If I load in EXRs, then sequencer_ibuf_get will still get me a PNG? Still needs more investigation...

Can confirm.

@Paul (Thirio) The Text Block Anchors icons mentioned above are now included in Blender. Maybe 'anchor' is a better name than 'origin'?

The result of bilinear scaling = nearest scaling for negative integer powers of 2.

No bug here, this is just a consequence of using exact 0.5 factor (other factors do give different results with bilinear vs nearest point methods).

Then it is the same issue as D6148 has fixed in VSE. I have tested functionality in clip editor, but haven't checked undistorted proxies...

In D6856#162253, @Richard Antalik (ISS) wrote:

Can you create bugreport? I don't see bug when testing unpatched.

Can you create bugreport? I don't see bug when testing unpatched.

Can reproduce in blender-2.83-6fff73e3f001-windows64 There's a D6786: VSE: Refactor proxy loading diff that fixes this, will confirm for now...

What's the status on this?

I don't think this will be fixed anytime soon.
Marking as Known Issue then.

The Prefetch Cache is actually slowing strip-grab operations down that much(on large resolution video clips), that on a low spec computer, that it would feel like a serious regression. Of course you could switch it off for each grab operation, which is a far from optimal workflow.

#ISS suggest to close, see: https://code.blender.org/2019/12/tracker-curfew/

I can not see difference here either.

I will update the icon sheet shortly

I don't see any differences in undo operations on my system. (sorry)
But it is very laggy when moving a strip after the playhead, 'cause as soon as the strip changes channels the prefetch starts.
Manually scrubbing the timeline pauses prefetch, perhaps if you're interacting with strips that affect the preview it just pauses by default, that would speed up concentrated edits.
I would assume this is a known issue though...

In T73453#861798, @Philipp Oeser (lichtwerk) wrote:

In contrast to T70457, this only seems to be an issue with Left-Click-Select?

In T71082#802737, @Andrzej Ambroz (jendrzych) wrote:

I just made set of icons, that would be descriptive enough for this function. Text Block Anchors:

CC @William Reynish (billreynish) , @Julian Eisel (Severin)

In contrast to T70457, this only seems to be an issue with Left-Click-Select?

Thanks Richard for reopening it. I appreciate that.

Ah I forgot about shift + LMB.

This seems to be a problem specific of the Dilate/Erode node.
I think it deserves an investigation before it is considered a Known Issue.
But I fear that no one will work on it for the upcoming 6 months.

Reading more meta-data info would for sure be a nice to have feature, but that is absolutely not a bug… Thanks for the report anyway.

Without looking at code, I would guess that that’s some kind mismatch in undo types, between mask editing undo, and global memfile undo (which is the only one able to undo animation data changes I think) ?