Initial Stereo/MultiCam Support Commit#803
Conversation
You're right, combination of (in my opinion) the bad text input default style of vuetify elements and me becoming complacent after testing it a bunch. |
|
@f4str - thoughts? |
|
I think that looks a lot better. It's a lot more intuitive now that you need to set a camera name first before uploading any images/videos. |
|
expected date for merge: June 29th as per our discussions |
subdavis
left a comment
There was a problem hiding this comment.
I have just a little more to look at (multiCamUtils.ts) but I keep getting distracted and I want to throw this over the fence.
client/dive-common/apispec.ts
Outdated
| imageData: FrameImage[]; | ||
| videoUrl: string; | ||
| }>; | ||
| display: string; |
There was a problem hiding this comment.
Comment what this is. Also note if it will be removed once there's true multi-cam support?
client/dive-common/apispec.ts
Outdated
| display: string; | ||
| } | ||
|
|
||
| interface CustomMediaImportPayload { |
There was a problem hiding this comment.
Document what this is. Also, I tend to think of "Payload" as an import. Could we rename this to "MediaImportResponse" or something? I'm not sure "Custom" adds any meaning.
client/dive-common/apispec.ts
Outdated
|
|
||
| type DatasetType = 'image-sequence' | 'video'; | ||
| type MultiTrackRecord = Record<string, TrackData>; | ||
| type SubType = 'stereo' | 'multicam' | null; |
There was a problem hiding this comment.
"DatasetType" and "SubType" seem backwards as names?
A dataset could be stereo, multicam, or normal. Each camera can have a subtype image-sequence or video?
Perhaps subType should be DatasetType and DatasetType should be MediaType?
There was a problem hiding this comment.
Dataset is image-sequence | video | multi - I didn't add the multi to the common/apispec because it isn't supported on the Web side yet. I could add it but it would require some updating to other files outside of the desktop scope to support it. Maybe I should place a comment here?
So I could see having DatasetType renamed to MediaType where it has image-sequence | video | multi(desktop only) I think I would want to rename it on the Server backend in python as well at the same time (a lot more files touched).
SubType may more accurately be renamed as multiCamType? There are differences in pipelines than can only be run based on the subType. Stereo only pipelines vs Multicam only pipelines. This allows me to disable/enable pipelines without having to reach far down into the meta and create a computed property (especially in the future folder view on web). I could move this into camera object although we may want to use this same field for for future identification of specialized media outside of MultiCam subtypes. Like IR images may have special pipelines on them and can be designated using this field.
The secondary use of it is inside of the JSONMeta for the displaying of the icon indicating that the dataset is stereo (binocular icon) or multicam (burst image icon).
So I can move it into the camera field and remove the icon display capability in recents because I wouldn't know the type until I load the fully metadata Or I could rename it to something like multiCamSubType or multiCamType.
| type: Object, | ||
| default: () => ({}), | ||
| }, | ||
| subTypeList: { |
| // const allowedPatterns = /^detector_.+|^tracker_.+|^generate_.+|^utility_|^measurement\.gmm/; | ||
| // Disable measurement for now. | ||
| const allowedPatterns = /^detector_.+|^tracker_.+|^generate_.+|^utility_/; | ||
| const allowedPatterns = /^detector_.+|^tracker_.+|^generate_.+|^utility_|^measurement_gmm_.+/; |
There was a problem hiding this comment.
Remove the comments above?
| if (!recent.multiCam) { | ||
| if (recent.type === 'video') { | ||
| return 'mdi-file-video'; | ||
| if (recent.type === 'multi') { |
There was a problem hiding this comment.
Should you be checking subType here?
There was a problem hiding this comment.
right below that I check the subType if it is of type multi to either display the binoculars or the burst photos.
client/platform/desktop/constants.ts
Outdated
| transcodedImageFiles?: string[]; | ||
| transcodedVideoFile?: string; |
There was a problem hiding this comment.
nit: in DatasetMeta, the transcoded media keys are not nullable, they're empty string and empty array if unused. For consistency (and my poor brain) it would be nice if these matched.
| command.push(`-s ${arg}="${file}"`); | ||
| }); | ||
| multiOutFiles = {}; | ||
| Object.entries(outFiles).forEach(([key, val]) => { |
There was a problem hiding this comment.
key val => cameraName, fileName
| let destLoc = ''; | ||
| if (jsonMeta.multiCam) { | ||
| let breakFlag = false; | ||
| Object.entries(jsonMeta.multiCam.cameras).forEach(([key, val]) => { |
There was a problem hiding this comment.
key, val => cameraName, camera ?
| let breakFlag = false; | ||
| Object.entries(jsonMeta.multiCam.cameras).forEach(([key, val]) => { |
There was a problem hiding this comment.
Don't use forEach proto method in loops you need to break from, prefer for...of and break keyword
https://developer.mozilla.org/en-US/docs/Web/JavaScript/Reference/Statements/for...of
There was a problem hiding this comment.
This can be done but ESLint gets upset and requires // eslint-disable-next-line no-restricted-syntax mostly because it doesn't want you to use a for of like that. I think the for...of is cleaner than the break flag I was using which was causing additional iterations.
There was a problem hiding this comment.
I also usually forget that for...of and for...in require RegeneratorRuntime, which I avoid like the plague.
You might just need a regular for loop here?
subdavis
left a comment
There was a problem hiding this comment.
Semi-populated form issue
When you start to work on a multi-cam import, and you create some named cameras, then you switch to keyword filter, you end up in a weird state where both exist. Same happens for stereo and multi.


Stereo requires calibration file (no change requested)
I'm not totally sure if it should. I understand that the stereo pipeline requires it, but maybe that should be an error thrown when the pipeline runs? Will anyone want to use stereo without the calibration file?
I think this is fine to leave alone as well, just wanted to leave a breadcrumb about this





I broke up the massive PR into smaller ones.
This is laying the foundation for being able to display the multicamera view as well as import annotation files through the UI.
After this I think I would be overhauling the import dialog so allow for individual annotation files per camera and I think I may want to have a discussion about import Dialogs and what we want to use.