Incorrect display of images extracted from rotated video (no zip chunks)

[phausamann]

Actions before raising this issue

• [X] I searched the existing issues and did not find anything similar.
• [X] I read/searched the docs

Steps to Reproduce

1. Create a video with a rotation record in the metadata, e.g. with ffmpeg -i <input_video> -c copy -metadata:s:v:0 rotate=90 <output_video>
2. Create a new task from the rotated video. Uncheck "prefer zip chunks"
3. Wait for the task to be created and open any job

Expected Behavior

The video images should be displayed correctly, taking into account the rotation. Instead, the image dimensions are correct, but the displayed image is warped:

Note that this doesn't occur when "prefer zip chunks" is checked.

Possible Solution

This seems to be a frontend issue, introduced in v2.6.0. My suspicion is this PR: https://github.com/opencv/cvat/pull/6585

The extracted images themselves are not affected. Downgrading the cvat_ui image version to v2.5.2 fixes the issue when opening the same task.

Context

No response

Environment

- Git hash a33f7f57, but can be reproduced with all versions >=2.6.0
- Ubuntu 20.04
- Docker version 24.0.1

[bsekachev]

Hello, Just keep in mind, that you may perform rotation in CVAT

[phausamann]

Thanks for the response @bsekachev , I am aware of that. However, our workflow assumes that a video with a rotation record is being uploaded.

[tahamukhtar20]

@nmanovic @bsekachev please assign me this issue.

[tahamukhtar20]

@nmanovic @bsekachev I didn't post a solution before for review, it skipped my mind that I had to do that, please let me know if there are any issues with this, and I'll reimplement that. I've already implemented this solution in the PR attached above, here is how I solved it currently, I noticed that this was working fine in v-2.5.1 and not in v-2.6.2 so I checked out the commits in between both versions and identified that the culprit was this piece of cvat-data code change in this commit. Now what I did was identify what was missing here, I noticed that imageBitmap was now being used across the entire application but something was missing that was in the previous PR that wasn't in this. which was that the crop image function's code was completely missing and that was why the issue was happening in the first place. So I added that in the code base in a way that nothing else was affected and tested it out in various environments making sure it worked for all types of images

[phausamann]

Thanks @tahamukhtar20 for the fix!