Fix included frames handling on UI #9155
Conversation
zhiltsov-max
force-pushed
the
zm/fix-included-frame-handling
branch
from
7a2e782 to
7a5dbdb
Compare
Codecov ReportAll modified and coverable lines are covered by tests ✅
Additional details and impacted files@@ Coverage Diff @@
## develop #9155 +/- ##
===========================================
+ Coverage 73.24% 73.32% +0.08%
===========================================
Files 447 448 +1
Lines 45837 45866 +29
Branches 3908 3915 +7
===========================================
+ Hits 33573 33632 +59
+ Misses 12264 12234 -30
|
cvat-core/src/frames.ts
Outdated
| @@ -208,7 +208,23 @@ export class FramesMetaData { | |||
| // it may be a videofile or one image | |||
| framesInfo = frameNumbers.map(() => initialData.frames[0]); | |||
| } else { | |||
| framesInfo = initialData.frames; | |||
| framesInfo = (() => { | |||
| if (initialData.frames.length > 1 && | |||
There was a problem hiding this comment.
there is condition initialData.frames.length === 1 above
There was a problem hiding this comment.
The solution with frame names looks like a dirty hack
What to you think about this one?
if (this.includedFrames?.length) {
// only gt jobs have this.includedFrame, so this condition works only for them
const framesIndexes = new Set(this.includedFrames.map((dataFrameNumber: number) => {
return Math.floor((dataFrameNumber - this.startFrame) / this.frameStep);
}));
framesInfo = initialData.frames.filter((_, idx) => framesIndexes.has(idx))
} else {
framesInfo = initialData.frames;
}There was a problem hiding this comment.
The solution with frame names looks like a dirty hack
Why it looks this way, if it's a constant defined by the server specifically for this?
What to you think about this one?
The formula part dataFrameNumber - this.startFrame is not correct in cases with nonzero start frame and frame step. In meta start_frame, stop_frame, and included_frames contain input data frame numbers (absolute ones). The correct way would be to obtain the original data frame number, then find the corresponding included_frames index.
There was a problem hiding this comment.
Why it looks this way, if it's a constant defined by the server specifically for this?
Because as you mentioned, user may have files named placeholder.jpg, what potentially may lead to bugs
We should not consider such solutions
There was a problem hiding this comment.
The formula part dataFrameNumber - this.startFrame is not correct in cases with nonzero start frame and frame step
I tested it in this case, and it seems to work in cases with non-zero start frame and frame step !== 1. Not really understand from your explanation why it should not.
In meta
start_frame,stop_frame, andincluded_framescontain input data frame numbers (absolute ones)
Yes. We want to map absolute frame number to segment frame number, using the formula above.
Then, as for GT jobs meta returns info about all frames in the task, from 1st one, we do assumption, that frame number == frame index.
There was a problem hiding this comment.
Ok, looks good to me. Added some explanatory comments why it works.
zhiltsov-max
force-pushed
the
zm/fix-included-frame-handling
branch
from
11a3be6 to
10fca7c
Compare
|
Motivation and context
Fixes #9097
/api/task|job/data/meta.framesincluded_framesfield in the related meta API response classHow has this been tested?
data_with_related_images.zip
random_200.zip
random_video_10s.mp4
Checklist
developbranchLicense
Feel free to contact the maintainers if that's a concern.