[Feature Request] Provide imagery tags

[justintuchek]

A really difficult part about using the SDK is using all of the captured media for photogrammetry after flying - for example using it with image stitching software, grouping media by session/flights, and identifying who the imagery is from and what it is needed for.

Considering the number of aerial data companies that use the SDK for construction, agriculture, and other commercialized workflow it be great to have a way to identify image and video assets by meta data to optimize the upload and processing part of this workflow.

I know the Camera APIs probably aren't intended or meant to expose things like file management and write capabilities - but being able to provide a few short properties to embed as EXIF data on write would be immensely valuable.

Such that on SDK initialization, or per request across the wire a developer could provide a few things to identify where they were sourced from and what they're for:

A String representing an image providers canonical name A String representing an image providers unique-ish identifier (such as GUID) A String settable post initialization that represents grouping, such as a flight or series of flights to be identified by an uploader or image processor.

This proposal would allow more automated tooling to be created around the uploading and processing of customers imagery, leading to less time spent digging through folders trying to gather all the correct media to do something with the assets they've generated.

[justintuchek]

Creating a list of media generated from a user session can be a really tedious/difficult thing to do, in the past we've tried a few different attempts such as:

• tracking diffs from the camera request for fetchMediaList but this has it's own performance problems that degrade as list get larger, it can be dependent on application runtime or pushes developers towards persisting those results
• collecting file names from the cameras mediaFileCreated, but this also depends on the application to be attached the entire time and still creates the problem of persisting results
• not all models even have a MediaManager instance available for the solutions above

I think the proposal above may be optimal because it

• doesn't depend on application runtime, so during a mission it can still write meta data tags if the tablet application fails or device loses power
• imposes less requirements on the media manager, and developers creating their own persistent mechanisms and diff/collection implementations
• could be implemented with a pretty minimal API addition that probably wouldn't affect the behavior of any other surface level calls in the SDK

[oliverou]

Hi @jtuchek , some of our products already support including custom info in the generated photos. The related interfaces are: https://developer.dji.com/api-reference/ios-api/Components/Camera/DJICamera.html#djicamera_camerasettings_setmediafilecustominformation_inline https://developer.dji.com/api-reference/ios-api/Components/Camera/DJIMediaManager_DJIMedia.html#djimediamanager_djimedia_custominformation_inline https://developer.dji.com/api-reference/ios-api/Components/Camera/DJIMediaManager_DJIMedia.html#djimediamanager_djimedia_fetchcustominformation_inline These interfaces are currently implemented on iOS SDK. Android will implement this feature in the coming versions. Do you think if this feature can fulfill your requirement?

[justintuchek]

@oliverou sort of - I wasn't aware that this existed, although I work exclusively in an Android application.

DJICamera.setMediaFileCustomInformation is pretty much exactly what I'm looking for - having it in the Android SDK would be great.

Could you discuss the aircraft compatibility roadmap for this feature? Docs stat "Only supported by Phantom 4 Pro, Phantom 4 Advanced and Inspire 2 with firmware released after May 23 2017."

My guess would be that it is a limitation/not implemented in other firmware versions for other devices? Would it be in the future?

It's the right approach, but it would be ideal to have a solution that (if some point in the future) worked for the complete offering - including the Mavic Pro, Matrice, etc. Otherwise we end up with branch upload support that only works for some models and not others.

[justintuchek]

@oliverou I do believe the implementation would fulfill the request.

Although more information could be helpful to prevent colliding identifiers between different SDK developers.

Such that two people implement some sort of auto-incrementing strategy (instead of GUIDs), they would at least be isolated by some sort of limited namespace.

[justintuchek]

Is there an update on this, it's been several months and releases?

[Michael-DJI]

it will be supported in Mavic 2 Enterprise drone.