Skip to content

Conversation

apetrynet
Copy link
Contributor

Hi!

I thought I'd put together a suggestion for how to implement ImageReference as mentioned in #69
Also added a test case to illustrate usage.

Let me know what you think.

apetrynet added 2 commits July 12, 2019 00:08
* Added clip.trimmed_range() override to support ImageReference
* Added tests case for ImageReference
@codecov-io
Copy link

Codecov Report

Merging #536 into master will decrease coverage by <.01%.
The diff coverage is 88.23%.

Impacted file tree graph

@@            Coverage Diff            @@
##           master    #536      +/-   ##
=========================================
- Coverage    88.8%   88.8%   -0.01%     
=========================================
  Files          68      69       +1     
  Lines        7399    7433      +34     
=========================================
+ Hits         6571    6601      +30     
- Misses        828     832       +4
Impacted Files Coverage Δ
opentimelineio/schema/clip.py 92.68% <100%> (+1.25%) ⬆️
opentimelineio/schema/__init__.py 100% <100%> (ø) ⬆️
opentimelineio/schema/image_reference.py 85.18% <85.18%> (ø)

Continue to review full report at Codecov.

Legend - Click here to learn more
Δ = absolute <relative> (impact), ø = not affected, ? = missing data
Powered by Codecov. Last update 36fab85...a160748. Read the comment docs.

@apetrynet
Copy link
Contributor Author

So, I realize the timing of this PR was quite bad (with the move to C++, SIGGRAPH and all), but has anyone had the chance to look at it and made any thoughts on it? Is it worth reproducing in C++?

@jminor
Copy link
Collaborator

jminor commented Aug 8, 2019

Hi @apetrynet! Yes, we did see this and a few people at SIGGRAPH mentioned the topic. Sorry for the delay in responding. As you mentioned, we were busy with the C++ port, and now we're beginning to move the project over to the Academy Software Foundation.

That will involve forming a technical steering committee who can help us decide, as a community, about the roadmap. One of the key things that the roadmap needs to include is schema improvements like this.

In effect that means that we're not quite ready to move forward with this yet, but we do hope to in the coming months.

As for the specifics of your proposal, here are a few things that come to mind:

  • Could you explain more about why frame_range could be different from available_range?
  • Could you add an example .otio file with an ImageReference in it?
  • Maybe ImageSequenceReference might be a better name to avoid confusion versus a single held image?
  • I'm sure people will have opinions about the %04d syntax.
  • We often see cases where people render every 2nd or 4th frame. Should that be represented as well?

@apetrynet
Copy link
Contributor Author

Hi!

Could you explain more about why frame_range could be different from available_range?

In my experience, almost all image based plates in a VFX pipeline have frame numbers starting at something else than what the TC would imply. Usually 1001-1200 etc. I don't know all the history for this, but it makes life easier using the plate in software like Maya, Nuke etc. to keep the timeline at a standard range. I seem to recall Maya actually having an issue with timelines that had really high numbered ranges.
By keeping the available_range in "sync" with the source TC and the frame_range with the renumbered frames on disk, we are able to maintain the metadata throughout the pipeline.

Maybe ImageSequenceReference might be a better name to avoid confusion versus a single held image?

Sure. Went back and forth on this myself. I haven't thought it through well enough yet, but this could also be used for held single frames though.

I'm sure people will have opinions about the %04d syntax.

Oh, yes. The everlasting debate on frame representation :)
There's no enforcing of the "%04d" in the code. Just used it as an example in the docstring since I find it the most common. It would be up to the developers using OTIO to decide which format suits them best I guess.

We often see cases where people render every 2nd or 4th frame. Should that be represented as well?

True. I haven't thought about that yet. That's a tough one in any case. The TC duration could be "full length", but the data won't. How would this be reflected in other media? I think in a video container, this would remap the frame numbers to create a shortened video file.
However, I think they should be treated as missing frames in the application reading the files. So in OTIO there shouldn't be a need to write any logic to support it(?)

Could you add an example .otio file with an ImageReference in it?

Sure. Will add it to the PR

@apetrynet
Copy link
Contributor Author

@jminor @reinecke I'll just close this PR then right?

@reinecke
Copy link
Collaborator

@apetrynet As long as you're happy with #602 :)

@apetrynet
Copy link
Contributor Author

I'm confident we'll land a good solution with that one, yes :)
Thanks!

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

Successfully merging this pull request may close these issues.

4 participants