Date   
Re: TimeCode frame limitation

Nick Porcino
 

I haven't heard of TLX. Thanks for bringing it up and providing some links to begin reading from. I wasn't aware that PTP has a microsecond precision though, I thought that was only a guarantee on synchrony, and hadn't pursued it further.

It seems the TLX group have come to same conclusion as OTIO, from the Medium article:

“The traditional approach was to adopt a clock frequency that had an integer relationship to all of the required rates,” he says. “If you consider just 25 fps and 30 fps, you could use a clock of 150 Hz and accommodate everything with integers. But then, it gets more complicated when you introduce audio, and incredibly more complicated when you include the non-integer 1000/1001 frame rates. Today, we are seeing more and more frame rates coming along. Gradually, we realized that there isn’t a magic number. The key to the synchronization solution came when somebody pointed out that with modern technology, such as digital phase lock loops, it doesn’t matter. Provided the precision of the time information you are receiving is sufficient—you can generate any frequency you want. So that was the path for the synchronization standard, which says that from a single network signal, you can generate any set of timing signals you might need.”  

Chris Horvath's flicks library is a semi tongue in cheek reducto-ad-absurdum of the traditional approach.

I dug a bit from your links, and found this video: https://www.smpte.org/webcast/beyond-smpte-time-code-tlx-project?action A discussion of encoding begins at 23:30. At 34:20, we can see a TLX_PTP time stamp (48 bits representing seconds, 32 bits for nanoseconds), TLX_SourceID (hopefully not MAC as in the slide!), TLX_Count (which I assume is like an edge code).

A point where TLX and OTIO are disjunct is that TLX specifies a "digital birth certificate" for media, whereas OTIO specifies edit decisions, and therefore appear to be complementary rather than addressing the same domain. Inasmuch as TLX is a DBC, it does seem relevant to OpenEXR's domain. I'll bring the TLX representations to the OTIO team, there seems to be a rich vein to mine.

Once again, thanks for mentioning TLX, and if you are able to dig up any other information and technical details, it would be very timely as we are doing a deep dive on time and interval representation in OTIO at the moment.


On Sat, Aug 8, 2020 at 11:49 AM Joseph Goldstone <joseph.goldstone@...> wrote:
The SMPTE efforts for a successor to timecode had gotten lost for a while. After a rousing SMPTE Hollywood Section presentation by Howard Lukk, it went very low-profile. That said, it seems to have been revived. The successor is called TLX (“Extensible Time Label”, no idea why that ordering of letters), it’s based on PTP, AKA IEEE 1588, currently IEEE 1588:2019.  PTP claims to be capable of sub-microsecond accuracy, and is already used (heavily I believe) in SMPTE standards for video over IP (I should note that video over IP is much more likely to significantly appear in studio work first, and we will be seeing HD-SDI cables on-set for a long time). The point is that working PTP implementations do exist.

 The TLX group is formally known as “TC-32NF-80 DG Extensible Time Label (TLX)”. I was not a member of that group, but just joined it so as to follow what’s going on. There’s a Reddit article by Michael Goldman (SMPTE past President, maybe, or is that a different Goldman?), something of an interview with Peter Symes here. I see some friends’ names on there from Netflix and from InterDigital, the R&D group that was recently spun out of Technicolor. I will try and summarize what I find out. Nick, I am very curious as to whether OTIO is following TLX development.



On Aug 7, 2020, at 23:32, Nick Porcino <nick.porcino@...> wrote:

At the root of the issue, SMPTE frame coding was a (ahem) clever method of conflating both endogenous media time with an edge code or frame code.

In OpenTime we address that explicitly by representing both the rate and the count to make a single time value.

I think this approach will stand the test of time, and I prefer it to playing cat and mouse with framerate-of-the-year. It also makes variable framerate within a single media reference a non-issue and doesn't impose any sort of requirement that all the framerates within the media be derived from a lowest common multiple.

On Aug 7, 2020, at 08:27, Brendan Bolles <brendan@...> wrote:

On Fri, Aug 7, 2020 at 03:52 AM, Eskil Steenberg wrote:
Do we want to support variable frame rate? GPUs produce and a lot of
displays support variable frame rate.

One option would be to store absolute time in the file, which would give you variable frame rate support and TimeCode could be calculated from it.

But in the meantime, does anyone else like this idea of violating SMPTE 12M-1999 to support higher frame rates with the current format? Seems like the benefit of the higher frame rates outweighs the disadvantage of not storing conforming binary data, which I'm not convinced anyone is accessing anyway. If we were really willing to abuse SMPTE 12M-1999, we could go all the way to 160 fps.



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982

Re: TimeCode frame limitation

Brendan Bolles
 

I think you want to be able to specify time as either a double OR as a ratio of integers, like a union in C. Integers are better for a standard frame rates, but if you want to specify some arbitrary time for a variable frame rate or something, you want a double.


On Sat, Aug 8, 2020 at 12:05 PM, Eskil Steenberg wrote:
I agree. The one issue I have with how OpenTime does it, is that its
encoded in to JSON, and JSON makes everything doubles, and doubles are
not precise. I had to implement a my own JSON parser, that didn't
convert ASCII numbers in to doubles, but to integers with a separate
decimal point position integer, when implementing OpenTime. My
preference, would be to modify it slightly and use integers. One frame
number, and a rational for the frame rate, so frame 3 on a NTSC frame
rate would be encoded as: 3 / (2997 / 100)

Cheers

E

Re: TimeCode frame limitation

Eskil Steenberg
 

Hi!

In OpenTime we address that explicitly by representing both the rate
and the count to make a single time value.
I think this approach will stand the test of time, and I prefer it to
playing cat and mouse with framerate-of-the-year. It also makes
variable framerate within a single media reference a non-issue and
doesn't impose any sort of requirement that all the framerates within
the media be derived from a lowest common multiple.
I agree. The one issue I have with how OpenTime does it, is that its encoded in to JSON, and JSON makes everything doubles, and doubles are not precise. I had to implement a my own JSON parser, that didn't convert ASCII numbers in to doubles, but to integers with a separate decimal point position integer, when implementing OpenTime. My preference, would be to modify it slightly and use integers. One frame number, and a rational for the frame rate, so frame 3 on a NTSC frame rate would be encoded as: 3 / (2997 / 100)

Cheers

E

Re: TimeCode frame limitation

Joseph Goldstone
 

The SMPTE efforts for a successor to timecode had gotten lost for a while. After a rousing SMPTE Hollywood Section presentation by Howard Lukk, it went very low-profile. That said, it seems to have been revived. The successor is called TLX (“Extensible Time Label”, no idea why that ordering of letters), it’s based on PTP, AKA IEEE 1588, currently IEEE 1588:2019.  PTP claims to be capable of sub-microsecond accuracy, and is already used (heavily I believe) in SMPTE standards for video over IP (I should note that video over IP is much more likely to significantly appear in studio work first, and we will be seeing HD-SDI cables on-set for a long time). The point is that working PTP implementations do exist.

 The TLX group is formally known as “TC-32NF-80 DG Extensible Time Label (TLX)”. I was not a member of that group, but just joined it so as to follow what’s going on. There’s a Reddit article by Michael Goldman (SMPTE past President, maybe, or is that a different Goldman?), something of an interview with Peter Symes here. I see some friends’ names on there from Netflix and from InterDigital, the R&D group that was recently spun out of Technicolor. I will try and summarize what I find out. Nick, I am very curious as to whether OTIO is following TLX development.



On Aug 7, 2020, at 23:32, Nick Porcino <nick.porcino@...> wrote:

At the root of the issue, SMPTE frame coding was a (ahem) clever method of conflating both endogenous media time with an edge code or frame code.

In OpenTime we address that explicitly by representing both the rate and the count to make a single time value.

I think this approach will stand the test of time, and I prefer it to playing cat and mouse with framerate-of-the-year. It also makes variable framerate within a single media reference a non-issue and doesn't impose any sort of requirement that all the framerates within the media be derived from a lowest common multiple.

On Aug 7, 2020, at 08:27, Brendan Bolles <brendan@...> wrote:

On Fri, Aug 7, 2020 at 03:52 AM, Eskil Steenberg wrote:
Do we want to support variable frame rate? GPUs produce and a lot of
displays support variable frame rate.

One option would be to store absolute time in the file, which would give you variable frame rate support and TimeCode could be calculated from it.

But in the meantime, does anyone else like this idea of violating SMPTE 12M-1999 to support higher frame rates with the current format? Seems like the benefit of the higher frame rates outweighs the disadvantage of not storing conforming binary data, which I'm not convinced anyone is accessing anyway. If we were really willing to abuse SMPTE 12M-1999, we could go all the way to 160 fps.

Re: TimeCode frame limitation

Nick Porcino
 

At the root of the issue, SMPTE frame coding was a (ahem) clever method of conflating both endogenous media time with an edge code or frame code.

In OpenTime we address that explicitly by representing both the rate and the count to make a single time value.

I think this approach will stand the test of time, and I prefer it to playing cat and mouse with framerate-of-the-year. It also makes variable framerate within a single media reference a non-issue and doesn't impose any sort of requirement that all the framerates within the media be derived from a lowest common multiple.

On Aug 7, 2020, at 08:27, Brendan Bolles <brendan@...> wrote:

On Fri, Aug 7, 2020 at 03:52 AM, Eskil Steenberg wrote:
Do we want to support variable frame rate? GPUs produce and a lot of
displays support variable frame rate.

One option would be to store absolute time in the file, which would give you variable frame rate support and TimeCode could be calculated from it.

But in the meantime, does anyone else like this idea of violating SMPTE 12M-1999 to support higher frame rates with the current format? Seems like the benefit of the higher frame rates outweighs the disadvantage of not storing conforming binary data, which I'm not convinced anyone is accessing anyway. If we were really willing to abuse SMPTE 12M-1999, we could go all the way to 160 fps.

Re: TimeCode frame limitation

Brendan Bolles
 

On Fri, Aug 7, 2020 at 03:52 AM, Eskil Steenberg wrote:
Do we want to support variable frame rate? GPUs produce and a lot of
displays support variable frame rate.

One option would be to store absolute time in the file, which would give you variable frame rate support and TimeCode could be calculated from it.

But in the meantime, does anyone else like this idea of violating SMPTE 12M-1999 to support higher frame rates with the current format? Seems like the benefit of the higher frame rates outweighs the disadvantage of not storing conforming binary data, which I'm not convinced anyone is accessing anyway. If we were really willing to abuse SMPTE 12M-1999, we could go all the way to 160 fps.

Re: TimeCode frame limitation

Eskil Steenberg
 

Hi!

I'm not entirely convinced making a new standard is the right
solution to having too many standards!
It depends. I just implemented ACES, and given that the spec asks me to implement various attribute types that could be used to express frame numbers, having a separate timecode type, means its more work. Granted, maybe a lot of people are already sitting on implementations.

It is worth considering how that standard works: for 120 fps there are
30 'superframes' per second, which are subdivided into four subframes.
So, frame 119 is encoded as superframe 29, subframe 3 (i.e. frame 119
is actually frame 29¾).
I know there is a Harry Potter joke hiding somewhere here...

So this means that the frame rate still has to be divisible by the superframes? The added implementation burden of this, paired with the shaky backwards compatibility (If you feed multiple frames with the same time superframes to an implementation that doesn't support subframes, is the result predictable and desirable?), It might make sense to make a clean break.

Do we want to support variable frame rate? GPUs produce and a lot of displays support variable frame rate.

Cheers

E

Re: TimeCode frame limitation

Peter Hillman
 


I'm not entirely convinced making a new standard is the right solution to having too many standards!

SMPTE-ST 12-3:2016 does describe how higher than 120 fps framerates would be supported, and apparently has reserved fields for that.

It is worth considering how that standard works: for 120 fps there are 30 'superframes' per second, which are subdivided into four subframes. So, frame 119 is encoded as superframe 29, subframe 3 (i.e. frame 119 is actually frame 29¾). This seems quite elegant to me. I would imagine it is useful to have a standard-frame-rate version of high-frame-rate sequences. The standard-frame-rate timecode is "just" the superframe number. This means discussions about timecode can happen without ambiguity about whether the standard or high framerate versions are being referenced. This is also nice where there are high-frame-rate cameras running in sync with standard-frame-rate picture cameras: everything has identical timecode, even if it's running at a different framerate, but every High Frame Rate frame gets a unique timecode (this all assumes the High frame rate is an exact multiple of the standard frame rate)

Following a similar technique in OpenEXR, perhaps the frame rate could be divided to reach a timecode less than 40 fps, and that stored in the standard timecode attribute, then a separate attribute used to encode which subframe is being recorded. There are a few user-data and other fields in the timecode which could be appropriated for the subframe, but that might conflict with other uses of those fields.


On 7/08/20 11:10 am, Brendan Bolles wrote:
Ah, standards. Do you think people are passing binary time code to/from EXR files? We could use the packing parameter to store more bits but still hand back legit SMPTE 12M-1999 by default. That would at least get us to 100 fps without breaking anything.

Yes, it appears SMPTE-ST 12-3:2016 will support up to 120 fps, but what happens when someone wants to go higher? Maybe we should come up with our own time code storage, or an official string attribute.

So right now if someone wants to write time code for higher frame rate footage, we just shouldn't do it?

if(fps <= 40)
  addTimeCode(header, …);




On Thu, Aug 6, 2020 at 03:06 PM, Peter Hillman wrote:

Unfortunately it is intentional - it's the SMPTE 12M-1999 standard. That uses binary coded decimal, allocating separate fields for the 'tens' and 'units' of the frame number, with two bits for the frame tens, meaning the maximum frame number that can be stored is 39.

I would be keen for OpenEXR to support higher frame rate timecodes. I believe SMPTE-ST 12-3:2016 will do that. It would be a little tricky to do that in a backwards compatible way. Perhaps the updated library could write two different timecode attributes, and would essentially ignore the old attribute on read if the new one is also present. The Imf::TimeCode attribute would have to change and gain extra functions to access the high-frame-rate 'subframe' component of the timecode.

Only throwing an error above 59 is definitely a bug, but that should throw above 39. I think it will write junk timecodes between 40 and 59, which we should fix

 

On 7/08/20 9:30 am, Brendan Bolles wrote:
The TimeCode object is unable to store frame numbers higher than 39, meaning that 40 fps is the maximum we can store TimeCode for. I don't think this is intentional, as it only throws an error if the value is above 59 as seen here. Still, I don't see why it shouldn't allow up to 99.

Thoughts?


Brendan

Re: TimeCode frame limitation

Paul Miller
 

Surely 100fps out to be enough for anybody.
😉

On Thu, Aug 6, 2020, 6:11 PM Brendan Bolles <brendan@...> wrote:
Ah, standards. Do you think people are passing binary time code to/from EXR files? We could use the packing parameter to store more bits but still hand back legit SMPTE 12M-1999 by default. That would at least get us to 100 fps without breaking anything.

Yes, it appears SMPTE-ST 12-3:2016 will support up to 120 fps, but what happens when someone wants to go higher? Maybe we should come up with our own time code storage, or an official string attribute.

So right now if someone wants to write time code for higher frame rate footage, we just shouldn't do it?

if(fps <= 40)
  addTimeCode(header, …);




On Thu, Aug 6, 2020 at 03:06 PM, Peter Hillman wrote:

Unfortunately it is intentional - it's the SMPTE 12M-1999 standard. That uses binary coded decimal, allocating separate fields for the 'tens' and 'units' of the frame number, with two bits for the frame tens, meaning the maximum frame number that can be stored is 39.

I would be keen for OpenEXR to support higher frame rate timecodes. I believe SMPTE-ST 12-3:2016 will do that. It would be a little tricky to do that in a backwards compatible way. Perhaps the updated library could write two different timecode attributes, and would essentially ignore the old attribute on read if the new one is also present. The Imf::TimeCode attribute would have to change and gain extra functions to access the high-frame-rate 'subframe' component of the timecode.

Only throwing an error above 59 is definitely a bug, but that should throw above 39. I think it will write junk timecodes between 40 and 59, which we should fix

 

On 7/08/20 9:30 am, Brendan Bolles wrote:
The TimeCode object is unable to store frame numbers higher than 39, meaning that 40 fps is the maximum we can store TimeCode for. I don't think this is intentional, as it only throws an error if the value is above 59 as seen here. Still, I don't see why it shouldn't allow up to 99.

Thoughts?


Brendan

Re: TimeCode frame limitation

Brendan Bolles
 

Ah, standards. Do you think people are passing binary time code to/from EXR files? We could use the packing parameter to store more bits but still hand back legit SMPTE 12M-1999 by default. That would at least get us to 100 fps without breaking anything.

Yes, it appears SMPTE-ST 12-3:2016 will support up to 120 fps, but what happens when someone wants to go higher? Maybe we should come up with our own time code storage, or an official string attribute.

So right now if someone wants to write time code for higher frame rate footage, we just shouldn't do it?

if(fps <= 40)
  addTimeCode(header, …);




On Thu, Aug 6, 2020 at 03:06 PM, Peter Hillman wrote:

Unfortunately it is intentional - it's the SMPTE 12M-1999 standard. That uses binary coded decimal, allocating separate fields for the 'tens' and 'units' of the frame number, with two bits for the frame tens, meaning the maximum frame number that can be stored is 39.

I would be keen for OpenEXR to support higher frame rate timecodes. I believe SMPTE-ST 12-3:2016 will do that. It would be a little tricky to do that in a backwards compatible way. Perhaps the updated library could write two different timecode attributes, and would essentially ignore the old attribute on read if the new one is also present. The Imf::TimeCode attribute would have to change and gain extra functions to access the high-frame-rate 'subframe' component of the timecode.

Only throwing an error above 59 is definitely a bug, but that should throw above 39. I think it will write junk timecodes between 40 and 59, which we should fix

 

On 7/08/20 9:30 am, Brendan Bolles wrote:
The TimeCode object is unable to store frame numbers higher than 39, meaning that 40 fps is the maximum we can store TimeCode for. I don't think this is intentional, as it only throws an error if the value is above 59 as seen here. Still, I don't see why it shouldn't allow up to 99.

Thoughts?


Brendan

Re: TimeCode frame limitation

Nick Porcino
 

We're working on bringing our SMPTE timecode parser up to spec in OpenTimelineIO, as well as making our parser robust enough to deal with all the weird variants we've encountered in the wild. If we do anything in OpenEXR, let's coordinate with OTIO to make sure we've at least compared notes.


On Thu, Aug 6, 2020 at 3:06 PM Peter Hillman <work@...> wrote:

Unfortunately it is intentional - it's the SMPTE 12M-1999 standard. That uses binary coded decimal, allocating separate fields for the 'tens' and 'units' of the frame number, with two bits for the frame tens, meaning the maximum frame number that can be stored is 39.

I would be keen for OpenEXR to support higher frame rate timecodes. I believe SMPTE-ST 12-3:2016 will do that. It would be a little tricky to do that in a backwards compatible way. Perhaps the updated library could write two different timecode attributes, and would essentially ignore the old attribute on read if the new one is also present. The Imf::TimeCode attribute would have to change and gain extra functions to access the high-frame-rate 'subframe' component of the timecode.

Only throwing an error above 59 is definitely a bug, but that should throw above 39. I think it will write junk timecodes between 40 and 59, which we should fix


On 7/08/20 9:30 am, Brendan Bolles wrote:
The TimeCode object is unable to store frame numbers higher than 39, meaning that 40 fps is the maximum we can store TimeCode for. I don't think this is intentional, as it only throws an error if the value is above 59 as seen here. Still, I don't see why it shouldn't allow up to 99.

Thoughts?


Brendan



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982

Re: TimeCode frame limitation

Peter Hillman
 

Unfortunately it is intentional - it's the SMPTE 12M-1999 standard. That uses binary coded decimal, allocating separate fields for the 'tens' and 'units' of the frame number, with two bits for the frame tens, meaning the maximum frame number that can be stored is 39.

I would be keen for OpenEXR to support higher frame rate timecodes. I believe SMPTE-ST 12-3:2016 will do that. It would be a little tricky to do that in a backwards compatible way. Perhaps the updated library could write two different timecode attributes, and would essentially ignore the old attribute on read if the new one is also present. The Imf::TimeCode attribute would have to change and gain extra functions to access the high-frame-rate 'subframe' component of the timecode.

Only throwing an error above 59 is definitely a bug, but that should throw above 39. I think it will write junk timecodes between 40 and 59, which we should fix


On 7/08/20 9:30 am, Brendan Bolles wrote:
The TimeCode object is unable to store frame numbers higher than 39, meaning that 40 fps is the maximum we can store TimeCode for. I don't think this is intentional, as it only throws an error if the value is above 59 as seen here. Still, I don't see why it shouldn't allow up to 99.

Thoughts?


Brendan

TimeCode frame limitation

Brendan Bolles
 

The TimeCode object is unable to store frame numbers higher than 39, meaning that 40 fps is the maximum we can store TimeCode for. I don't think this is intentional, as it only throws an error if the value is above 59 as seen here. Still, I don't see why it shouldn't allow up to 99.

Thoughts?


Brendan

Re: 2.5.3 release?

Nick Porcino
 

This looks good to me, thanks for pulling together such thorough notes!

Since #794 introduces a new function signature, as opposed to modifying an existing one, it shouldn't introduce dynamic linking issues, and therefore doesn't to my estimation constitute an ABI breakage.

On Wed, Aug 5, 2020 at 1:07 PM Cary Phillips <cary@...> wrote:
Before moving to the 3.0 release, we should make another minor/patch release. The changes since 2.5.2 include:
  1. various sanitizer/fuzz-identified issues related to handling of invalid input.
  2. fixes to misc compiler warnings.
  3. cmake fix for building on arm64 macOS (#772)
  4. fixes to tests
  5. read performance optimization (#782)
  6. fix for building on non-glibc (#798)
All changes are binary compatible, with one possible exception: #794 provides a new template specialization, for ImfAttribute<T>::copyValuesFrom(), to suppress clang sanitizer undefined behavior warnings. Is this technically ABI-compatible? In this specific instance, the change is simply a warning suppression, so not code actually changed.

Unless anyone suggests something different, I propose to merge all of these changes into the RB-2.5 branch and make the new release 2.5.3. This would make all bug/vulnerability/build fixes available prior to 3.0, along with Foundry's read performance optimizations, leaving the 3.0 release as purely repo restructuring, which seems worthwhile.

Here is the complete list of pull requests that would go into 2.5.3:

https://github.com/AcademySoftwareFoundation/openexr/pull/738 always ignore chunkCount attribute unless it cannot be computed #738
https://github.com/AcademySoftwareFoundation/openexr/pull/770 IlmImf: Fix clang compiler warnings
https://github.com/AcademySoftwareFoundation/openexr/pull/772 Disable OPENEXR_IMF_HAVE_GCC_INLINE_ASM_AVX when building on arm64 macOS
https://github.com/AcademySoftwareFoundation/openexr/pull/775 Removes overridden find_package in CMakeLists.txt
https://github.com/AcademySoftwareFoundation/openexr/pull/777 IlmImfFuzzTest reports incorrect test names and missing files as errors
https://github.com/AcademySoftwareFoundation/openexr/pull/778 Sanity check stringvector size fields on read
https://github.com/AcademySoftwareFoundation/openexr/pull/782 refactor: use local loop variable in copyFromFrameBuffer
https://github.com/AcademySoftwareFoundation/openexr/pull/783 explicitly cast signed chars to unsigned before bitwise left shift in Xdr::read()
https://github.com/AcademySoftwareFoundation/openexr/pull/784 sanity check preview attribute sizes
https://github.com/AcademySoftwareFoundation/openexr/pull/785 prevent invalid values in Channel's PixelType enum
https://github.com/AcademySoftwareFoundation/openexr/pull/787 change sanity check in stringvectorattribute to prevent overflow
https://github.com/AcademySoftwareFoundation/openexr/pull/788 use 64 bit computation in chunk offset table reconstruction
https://github.com/AcademySoftwareFoundation/openexr/pull/792 cast signed chars to unsigned longs before left shift in Xdr::read of signed long
https://github.com/AcademySoftwareFoundation/openexr/pull/793 sanityCheckDisplayWindow() ensures that width and height don't cause integer overflow
https://github.com/AcademySoftwareFoundation/openexr/pull/794 suppress clang undefined behavior sanitizer in DeepImageStateAttribute::copyValuesFrom()
https://github.com/AcademySoftwareFoundation/openexr/pull/795 prevent invalid values in LineOrder enum
https://github.com/AcademySoftwareFoundation/openexr/pull/798 IexMathFpu.cpp: Fix build on non-glibc (e.g. musl libc)
https://github.com/AcademySoftwareFoundation/openexr/pull/804 prevent invalid tile description enums
https://github.com/AcademySoftwareFoundation/openexr/pull/803 Fix stack corruption in Matrix tests
https://github.com/AcademySoftwareFoundation/openexr/pull/801 prevent invalid Compression enum values being read from file



--
Cary Phillips | R&D Supervisor | ILM | San Francisco



--
--------------------------------
Nick Porcino @meshula
Virtual and augmented production, interactive applications, and robotics, since 1982

2.5.3 release?

Cary Phillips
 

Before moving to the 3.0 release, we should make another minor/patch release. The changes since 2.5.2 include:
  1. various sanitizer/fuzz-identified issues related to handling of invalid input.
  2. fixes to misc compiler warnings.
  3. cmake fix for building on arm64 macOS (#772)
  4. fixes to tests
  5. read performance optimization (#782)
  6. fix for building on non-glibc (#798)
All changes are binary compatible, with one possible exception: #794 provides a new template specialization, for ImfAttribute<T>::copyValuesFrom(), to suppress clang sanitizer undefined behavior warnings. Is this technically ABI-compatible? In this specific instance, the change is simply a warning suppression, so not code actually changed.

Unless anyone suggests something different, I propose to merge all of these changes into the RB-2.5 branch and make the new release 2.5.3. This would make all bug/vulnerability/build fixes available prior to 3.0, along with Foundry's read performance optimizations, leaving the 3.0 release as purely repo restructuring, which seems worthwhile.

Here is the complete list of pull requests that would go into 2.5.3:

https://github.com/AcademySoftwareFoundation/openexr/pull/738 always ignore chunkCount attribute unless it cannot be computed #738
https://github.com/AcademySoftwareFoundation/openexr/pull/770 IlmImf: Fix clang compiler warnings
https://github.com/AcademySoftwareFoundation/openexr/pull/772 Disable OPENEXR_IMF_HAVE_GCC_INLINE_ASM_AVX when building on arm64 macOS
https://github.com/AcademySoftwareFoundation/openexr/pull/775 Removes overridden find_package in CMakeLists.txt
https://github.com/AcademySoftwareFoundation/openexr/pull/777 IlmImfFuzzTest reports incorrect test names and missing files as errors
https://github.com/AcademySoftwareFoundation/openexr/pull/778 Sanity check stringvector size fields on read
https://github.com/AcademySoftwareFoundation/openexr/pull/782 refactor: use local loop variable in copyFromFrameBuffer
https://github.com/AcademySoftwareFoundation/openexr/pull/783 explicitly cast signed chars to unsigned before bitwise left shift in Xdr::read()
https://github.com/AcademySoftwareFoundation/openexr/pull/784 sanity check preview attribute sizes
https://github.com/AcademySoftwareFoundation/openexr/pull/785 prevent invalid values in Channel's PixelType enum
https://github.com/AcademySoftwareFoundation/openexr/pull/787 change sanity check in stringvectorattribute to prevent overflow
https://github.com/AcademySoftwareFoundation/openexr/pull/788 use 64 bit computation in chunk offset table reconstruction
https://github.com/AcademySoftwareFoundation/openexr/pull/792 cast signed chars to unsigned longs before left shift in Xdr::read of signed long
https://github.com/AcademySoftwareFoundation/openexr/pull/793 sanityCheckDisplayWindow() ensures that width and height don't cause integer overflow
https://github.com/AcademySoftwareFoundation/openexr/pull/794 suppress clang undefined behavior sanitizer in DeepImageStateAttribute::copyValuesFrom()
https://github.com/AcademySoftwareFoundation/openexr/pull/795 prevent invalid values in LineOrder enum
https://github.com/AcademySoftwareFoundation/openexr/pull/798 IexMathFpu.cpp: Fix build on non-glibc (e.g. musl libc)
https://github.com/AcademySoftwareFoundation/openexr/pull/804 prevent invalid tile description enums
https://github.com/AcademySoftwareFoundation/openexr/pull/803 Fix stack corruption in Matrix tests
https://github.com/AcademySoftwareFoundation/openexr/pull/801 prevent invalid Compression enum values being read from file



--
Cary Phillips | R&D Supervisor | ILM | San Francisco

Implementing the ACES spec

Eskil Steenberg
 

Hi!

After lurking around in the mailing list for a while and in some meetings I have finally found some time to write my own implementation of ACES. (See attached screenshot!)

In general I find that implementing the ACES spec is pretty straight forward. However I do have some minor notes, but first a big disclaimer: I used the draft specification Version 26 dated 2019-12-12 , so any of this may be out of date.

Anyhow, here we go:

-I find that ACES is a great subsection of OpenEXR, but backwards compatibility with OpenEXR breaks in some places. It's not clear if it's meant to be forward or backwards compatible.

-ACES requires some attributes that don't have to be present in OpenEXR, it would be good to note in the spec that files with OpenEXR version numbers don't have the same requirements. A parser written to reject a non standard files breaks on files due to this.

-Even though ACES doesn't support , multisampling, float,int types, or more than 8 channels, I still think it makes sense to describe them in the spec so that implementations can skip channels with this data or choose to implement them. I think the best would be to require a ACES implementation not to break if non ACES channels are present, but not be requirer to parse or use them.

-The only vector types in the spec are v2f and v3f. Loads of files OpenEXR store v3i, m44f, m33d and a host of other vector formats. I think it would be good to express this in the format spec. I feel that the lack of matrix data types is a big loss as few things are as important in a VFX context as camera matrices. It would be good to have a standardized specification of this. Like what types are allowed? can we use "s", "l", "h" for short, long, and half, or is there a limit to what types can be used in vectors? What about unsigned values? Another question is if matrices can be larger then 9*9, and if so how would one parse m414f? is it a 41 * 4 matrix or a 4 * 14 matrix?

-The stringVector spec description is not very clear. I had to look at a file to figure it out. Note 1 is just confusing (and not very accurate) and should be removed. There is a note for the string type that says that the length of the string does not have to be stored in the string, because the attribute provides this. When you then read the stringVector vector description, you feel like there is some kind of similar omission, but there isn't.

-There is no clear description of the relation between line offset table, scanline objects and the line order attribute. What is authoritative? Can one skip the line offset table and just assume that all line objects are to be found directly after? Or is the offset table authoritative? If so can it point to the same data multiple times? And can an implementation put random filler between scanline objects? The offset table allows me to store scanlines in random order in the file, and then the scanlines can again have another level of indirection because they store their y position. Or are scanline y positions not authoritative? In that case you can have a file where every line in the scanline table points to the same scanline if you want something like a black screen. Then on top of that there is a line order attribute. Is that a hint to the order I can expect to find the data in the file and/or offset table, or should I flip my image according to this attribute?

Given that there is no specification for OpenEXR, I found the ACES spec very valuable. I would love to see an additional document that outlines some of the things that have been omitted. The lossless compression schemes comes to mind. ACES is clearly designed for film making, but given that there are almost no alternatives for storing HRD images, I think very small additions could make it invaluable as an open standard to VFX and Games too. This is why I also think that making the final specification available is really important. Even as an end user of software that uses something like this it's important to be able look up what things really mean.

I will be releasing my code as open source hopefully soon.

Cheers

E

Transition to new OpenEXR CCLA

John Mertic
 

OpenEXR Community,

The OpenEXR TSC has approved changing the current CLAs to instead use templates that are substantively based on the Apache Software Foundation's CLAs, with changes just for identifying the project and for administration through EasyCLA. This change was made after discussions from the ASWF Governing Board and Legal Committee. This transition will not be immediate, and the aim is to ensure minimal disruption for current contributors.

Once the transition happens, all contributions going forward will require the contributor or their affiliated contributing organization to sign the new CLA. The project will continue to leverage the EasyCLA service provided by the Linux Foundation.

As often for organizations it can take some time to have agreements reviewed and executed, we have enabled the ability for organizations to sign the new agreement and assign any CLA Manager(s) and authorized contributors prior to the switch over. Doing so will ensure there are no gaps in abilities to contribute from a legal perspective.

To sign the CCLA, please go to https://corporate.lfcla.com/ and select 'OpenEXR' as the project to complete the CCLA for. More information on the EasyCLA system can be found at https://docs.linuxfoundation.org/docs/communitybridge/easycla/ccla-managers-and-ccla-signatories.

Feel free to reach out if there are any questions or concerns.

Thank you,

John Mertic
Director of Program Management - Linux Foundation
ASWF, ODPi, and Open Mainframe Project
Schedule time with me at https://cal.mixmax.com/johnmertic

outstanding OpenEXR issues

Cary Phillips
 

Here are a few issues we should address before the upcoming major release, if anyone would care to comment, or even better, submit a PR, it would be helpful to do in the next week or so.

https://github.com/AcademySoftwareFoundation/openexr/issues/789
Better stream interface for DeepScanlineInputFile

https://github.com/AcademySoftwareFoundation/openexr/issues/773
PyIlmBase cmake is able to find Boost but not boost::python

https://github.com/AcademySoftwareFoundation/openexr/pull/750
Zero allocated memory to guarantee always identical output in DWAA compression

https://github.com/AcademySoftwareFoundation/openexr/issues/740
Remove deprecated argument to getChunkOffsetTableSize

https://github.com/AcademySoftwareFoundation/openexr/issues/548
mark half(float) constructor as explicit

https://github.com/AcademySoftwareFoundation/openexr/issues/485
Remove _maxScanLineSize members


--
Cary Phillips | R&D Supervisor | ILM | San Francisco

Re: OpenEXR TSC meeting (fortnightly) - Thu, 07/30/2020 1:30pm-2:30pm #cal-reminder

Joseph Goldstone
 

If I could get 3-4 minutes I’d like to talk about the pros and cons of implementing the attributes in the ACES Container spec (SMPTE ST 2065-4) in the reference implementation. Putting them in the reference implementation will effectively make them more portable. OTOH any organization using unqualified names (not ‘legal’ according to the spec, but of course the reference implementation doesn’t stop you from doing it) in a nonstandard way potentially could see an impact.

For reference:



And something I hope to submit shortly ti SMPTE, as it’s doing a belated 5-year review of ST 2065-4:2013:


Maybe deprecate illegal use of unqualified (standardized) names now, and post-3.0 sometime, add them in?

—Joseph

On Jul 30, 2020, at 12:25, Cary Phillips <cary@...> wrote:

Agenda for today:
  1. Update on Imath
    • current state of OpenEXR dependency
    • other issues and todo's
  2. Prep for ASWF Open Source Day
  3. Prep for 3.0 release
  4. Outstanding issues:

On Thu, Jul 30, 2020 at 7:30 AM openexr-dev@... Calendar <openexr-dev@...> wrote:

Reminder: OpenEXR TSC meeting (fortnightly)

When: Thursday, 30 July 2020, 1:30pm to 2:30pm, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/96214953481

View Event

Organizer: jmertic@... jmertic@...

Description: OpenEXR TSC Meeting

Join Zoom Meeting
https://zoom.us/j/96214953481

Meeting ID: 962 1495 3481
One tap mobile
+16465588656,,96214953481# US (New York)
+13017158592,,96214953481# US (Germantown)

Dial by your location
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
877 369 0926 US Toll-free
855 880 1246 US Toll-free
+1 778 907 2071 Canada
+1 438 809 7799 Canada
+1 587 328 1099 Canada
+1 647 374 4685 Canada
+1 647 558 0588 Canada
855 703 8985 Canada Toll-free
Meeting ID: 962 1495 3481
Find your local number: https://zoom.us/u/aLw9k3Nkj





-- 
Cary Phillips | R&D Supervisor | ILM | San Francisco


Re: OpenEXR TSC meeting (fortnightly) - Thu, 07/30/2020 1:30pm-2:30pm #cal-reminder

Cary Phillips
 

Agenda for today:
  1. Update on Imath
    • current state of OpenEXR dependency
    • other issues and todo's
  2. Prep for ASWF Open Source Day
  3. Prep for 3.0 release
  4. Outstanding issues:


On Thu, Jul 30, 2020 at 7:30 AM openexr-dev@... Calendar <openexr-dev@...> wrote:

Reminder: OpenEXR TSC meeting (fortnightly)

When: Thursday, 30 July 2020, 1:30pm to 2:30pm, (GMT-07:00) America/Los Angeles

Where:https://zoom.us/j/96214953481

View Event

Organizer: jmertic@... jmertic@...

Description: OpenEXR TSC Meeting

Join Zoom Meeting
https://zoom.us/j/96214953481

Meeting ID: 962 1495 3481
One tap mobile
+16465588656,,96214953481# US (New York)
+13017158592,,96214953481# US (Germantown)

Dial by your location
+1 646 558 8656 US (New York)
+1 301 715 8592 US (Germantown)
+1 312 626 6799 US (Chicago)
+1 669 900 6833 US (San Jose)
+1 253 215 8782 US (Tacoma)
+1 346 248 7799 US (Houston)
877 369 0926 US Toll-free
855 880 1246 US Toll-free
+1 778 907 2071 Canada
+1 438 809 7799 Canada
+1 587 328 1099 Canada
+1 647 374 4685 Canada
+1 647 558 0588 Canada
855 703 8985 Canada Toll-free
Meeting ID: 962 1495 3481
Find your local number: https://zoom.us/u/aLw9k3Nkj



--
Cary Phillips | R&D Supervisor | ILM | San Francisco