mean error buffer dropping every frame

[MarcelMB]

I am testing a ground truth video right now. With the gradient method, everything works smooth mostly to filter out frames with broken buffers.

However, using mean error filtering the last buffer 85 is always above 50 for every frame which can not be true and must be a bug of some sort that I haven't investigated further yet. Like every single frame has this and is therefore a false positive.
But only the last buffer

I am not using the test video jonny created or the test.avi that Takuya used for establishing the method. Those work fine for some reason but also the test.avi had more buffers per frame like 63 or 64
Its a different video from our December in vivo recordings. I uploaded it here. Video is trimmed so not a large data file. drive link to .avi

[sneakers-the-rat]

Oh yeah there should only be like 5 buffers per frame, right? That seems like a pretty likely source of the bug. If we are slicing the frame very small, if that last segment is tiny, like 5 pixels or something, then we would expect huge variance there.

[MarcelMB]

no there are more than 5 buffers per frame because in the mean method each buffer is split into smaller chunks to make it more sensitive

but yeah it should not be the the last chunk is super small

[t-sasatani]

My guess is the same as @sneakers-the-rat; the last chunks are probably too small here. That is kind of intentional because if the last chunk is small at transfer, it should be small during comparison, because this errors often happens in the unit of (part of) buffers. However, it's probably better to have a size limit with a warning. I'll hopefully look into this next week, along with the denoising PR.

[t-sasatani]

Calling this buffer is just bad terminology. I'll change this to blocks or something.

[t-sasatani]

@MarcelMB Is this recording with the same buffer_block_length and block_size as the one with the test video?

[MarcelMB]

It is from the invivo-20241203 recordings we did in December. I assume the test.avi you created is also from these files and they all had the same firmware in regard to this

[sneakers-the-rat]

What is the type of artifact/glitch we're detecting with this one again? is it for the cases where the values go to all 0's within a chunk? still unsure about why we wouldn't just be splitting this up into buffer sizes and comparing those between frames, since isn't it usually the case that corruption is confined to a buffer (or the latter portion of a buffer)?

[t-sasatani]

is it for the cases where the values go to all 0's within a chunk?

Initially, both the sandstorms and 0s, but we're not sure yet which is better so we're preparing whatever for benchmarking. It could all be replaced by gradient (or less likely, but the other way around).

the latter portion of a buffer

This is correct. I thought it would be hard to detect glitches that only happen in the last 10% of the buffer, so I chucked it up further than the buffer, which can be turned on/off anyway with the config. It should be better to compare the latter portion of the buffers with varied lengths, but it seemed too specific to start with (I didn't want to fully bet that glitches happen with this pattern before looking into detected broken frames), so it ended up this way for now.

[t-sasatani]

I will push this later, as getting back to regular operation is pretty complex once one false-negatives is detected. Might just get rid of the method later, but I guess we can keep it until we start fusing methods, etc.