Profiles & Formats (Non-Marker) (Count and Interval)

[IAmVigneswaran]

@orchetect

Currently, we use FCPXML to determine the image extraction points. I wonder what if we can have another method, a Non-Marker Profile for the image extraction?

Under Non-Marker profile we can have 2 modes, Count and Interval.

Example :

Count Mode

If the user specifies a count (e.g., 5), our extraction library/CLI will calculate the total duration of the video clip, divide it by the specified count, and use the derived time-codes to extract images at evenly spaced intervals.

Interval Mode

If the user specifies a time interval (e.g., 60 seconds), our extraction library/CLI will calculate the total duration of the video clip and extract images at every specified interval throughout the clip.

---

In terms of Marker Data's UI, we can have a new tab Non-Marker under Image. It can be only be selectable if Non-Marker Profile is selected.

For this profile, we don't create any .csv or .json.

This feature can be extremely useful for rapid image extraction especially for cataloguing and stock footages.

[orchetect]

The tool is specifically for extracting markers though, hence its name - MarkersExtractor. This feels outside the scope of its core purpose.

[IAmVigneswaran]

The tool is specifically for extracting markers though, hence its name - MarkersExtractor. This feels outside the scope of its core purpose.

While this feature may seem beyond the primary scope of our tool, as it does not directly involve the use of Markers or FCPXML, I believe it remains somewhat relevant to some extent since it involves extracting images from the video file, which aligns with the tool's broader functionality.

Situation 1 :

When working with stock and sample footage, the ability to quickly extract images can be highly beneficial. In cases where users handle 50 or more clips, they would typically need to create timelines individually and manually place Markers. By utilising the 'Non-Marker Profile' with the 'Count' and 'Interval' options, users can significantly streamline this process and save valuable time.

Situation 2 :

This feature can be beneficial for assistant editors tasked with organising stock and sample footage on a hard drive. With the ability to create an Image Card Summary File, assistants can easily generate an Image Card Summary and place it in the same folder as the stock footage. These Image Cards provide a quick reference for reviewing video content and can be easily shared via email or messaging platforms for approval and feedback.

[orchetect]

I don't doubt that it would be useful, but it does feel like it would be broadening the scope of the tool.

My only concern is that this pattern of feature creep may dilute the clarity of its use for newcomers and also add to tech debt sprawl. The amount of available options for the tool is already substantial. If there were to be generic processes added (such as this, which does not inherently rely on FCPXML and is really just a video processor) I would say it really necessitates the introduction of a new tool entirely that can compartmentalize its own parameters.

[IAmVigneswaran]

My only concern is that this pattern of feature creep may dilute the clarity of its use for newcomers and also add to tech debt sprawl. The amount of available options for the tool is already substantial.

True!

Recently, I had to organise a large amount of stock and sample footage, including the extraction of images. While our Marker Data App certainly accelerated my workflows and organisation, an idea pop into my mind, on the possibility image extraction without Markers.

This is certainly not an urgent request. Just want to pen down the idea for future reference.

I would say it really necessitates the introduction of a new tool entirely that can compartmentalize its own parameters.

Perhaps, a separate companion library?

[orchetect]

Perhaps, a separate companion library?

Yes, essentially. Something more generic. It could also cannibalize the code that was built in Marker Data to generate those color swatches on images (#47), which again, is something adjacent to our goals with processing videos but not really relating to markers or FCPXML.