Reorder attribute definitions in ImfStandardAttributes.h by functional group

[JGoldstone]

As discussed in last Thursday's TSC meeting, this is a reordering-only commit in ImfStandardAttributes.h. A good way to verify that is to make a copy of the unmodified file and sort its lines, redirecting the output to file X, and make a copy of the file after this commit and sort its lines, redirecting the output to file Y, and then diff X and Y. Of course both X and Y only contain uncompilable gibberish, but if you look at the output of the diff, the only difference is a few lines of whitespace have been added.

This was my guide to the re-ordering. Attributes in square brackets are actually in ImfHeader.h and not in ImfStandardAttributes.h. Attributes with two asterisks in front of them represent new attributes currently defined in SMPTE's camdkit repository. Otherwise unannotated attributes exist in today's ImfStandardAttributes.h.

[misc]

• [LineOrder]
• [Compression]

position and orientation of physical and CG camera at time of capture

• originalDataWindow
• worldToCamera
• worldToNDC
• [dataWindow]
• [displayWindow]
• [pixelAspectRatio]
• [screenWindowCenter]
• [screenWindowWidth]
• xDensity
• ** something to carry the dimensions of the active sensor area, in physical dimensions
• longitude
• latitude
• altitude

camera ID

• ** cameraMake
• ** cameraModel
• ** cameraSerialNumber
• ** cameraFirmwareVersion
• ** cameraUuid
• ** cameraLabel

camera state

• ** colorTemperature
• ** tint
• ** colorBalance [maybe?]
• isoSpeed
• ** exposureIndex [maybe?]
• expTime
• ** shutter angle
• ** captureRate
• ** timecodeRate

lens ID

• ** lensMake
• ** lensModel
• ** lensSerialNumber
• ** lensFirmwareVersion

lens state

• aperture
• ** deprecate aperture, replace with:
• ** fNumber
• ** tStop
• ** effectiveFocalLength
• ** nominalFocalLength
• ** pinholeFocalLength
• focus

editorial

• owner
• comments
• capDate
• utcOffset
• keyCode
• timeCode
• framesPerSecond
• ** imageCounter
• ** reelName
• ** FDL [ASC Framing Decision List]

encoded image color characteristics

• [chromaticities]
• whiteLuminance
• adoptedNeutral

anticipated color processing

• renderingTransform [eventually deprecate and delete]
• lookTransform [eventually deprecate and delete]

anticipated use in pipeline

• envmap
• wrapmodes
• multiView
• deepImageState
• idManifest

camera relationship to a CG environment

• originalDataView

[linux-foundation-easycla]

The committers listed above are authorized under a signed CLA.

• ✅ login: JGoldstone / name: Joseph Goldstone (0368f5c)

[meshula]

lgtm! @cary-ilm Do we have a CLA in place for Joseph already?

[JGoldstone]

I know that in Munich we took both the OpenEXR and OpenColorIO CCLAs through the legal department and got them signed by the GM at the same time. I know that the OCIO CCLA was valid when Sean Cooper added LogC4 support to OCIO, so the CLA admin at ARRI Munich must have done his part on that, right? I.e. am I right that once you get the paperwork signed, and conveyed somehow to the LF, that the next thing that must be done is something done by the CLA admin identified in the paperwork, and not the worker bee who happens to submit the first PR? If that is the case then perhaps something was done for OCIO by our Munich CLA but not for OpenEXR. That person happens to be one of the hardest people to corral in all of ARRIAL (the HQ building), so if I need to get him to do something, I am going to have to have every person he contacts on his next in-office workday ask him about the OpenEXR CLA.

…

On Apr 12, 2023, at 16:45, Nick Porcino ***@***.***> wrote: @meshula approved this pull request. lgtm! @cary-ilm <https://github.com/cary-ilm> Do we have a CLA in place for Joseph already? — Reply to this email directly, view it on GitHub <#1379 (review)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIVB7LNMXJO3AIKPFSBPTDXA4H5RANCNFSM6AAAAAAW3AIYFU>. You are receiving this because you were mentioned.

[meshula]

I suspect we have it (hence pinging Cary), and that it predates easycla. So we can shortcut the bot for merging the code with a confirmation, and look at setting you up in easycla separately.

[cary-ilm]

Either way, somebody from ARRI has to click through the red "NOT COVERED" EasyCLA links and electronically sign the forms. If a previous iteration of the form has been signed, then someone needs to add your name and email to the "approved" list, which I believe is also managed through that link (I've never actually seen that part of the interface because I'm not my org's CLA manager, so I'm in the same boat as you). There should be only one designed ARRI CLA manager, so the "CLA admin at ARRI Munich" should be able to execute for OpenEXR what they did for OCIO.

[cary-ilm]

In addition to the CLA, the commit also needs a signature, to fix the failing "DCO" check. Do:

git commit -amend -s
git push -f

[JGoldstone]

This part I did. I presume that as it’s still only in my fork, nothing need be done elsewhere? And is there a way to configure git to always use --amend?

…

On Apr 12, 2023, at 17:13, Cary Phillips ***@***.***> wrote: In addition to the CLA, the commit also needs a signature, to fix the failing "DCO" check. Do: git commit -amend -s git push -f — Reply to this email directly, view it on GitHub <#1379 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIVB7OCT7YCZRNVEDET73LXA4LIZANCNFSM6AAAAAAW3AIYFU>. You are receiving this because you were mentioned.

[cary-ilm]

Yes, that worked, all good, the DCO check has passed, thanks!

You don't regularly need the -amend, it's the -s that you should specify each time.

[JGoldstone]

Apologies for having misstated that. I meant how would I configure git to sign every commit. This (looking here <https://git-scm.com/docs/git-config#Documentation/git-config.txt-formatsignOff> ) appears as if it would do it, at the end of ~/.gitconfig [format] signoff = true Does that sound right to you?

…

On Apr 12, 2023, at 17:31, Cary Phillips ***@***.***> wrote: Yes, that worked, all good, the DCO check has passed, thanks! You don't regularly need the -amend, it's the -s that you should specify each time. — Reply to this email directly, view it on GitHub <#1379 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/AAIVB7NHSZFYV6MYHHBFN3TXA4NLNANCNFSM6AAAAAAW3AIYFU>. You are receiving this because you were mentioned.

[JGoldstone]

My CLA admin in Munich has added me and I've 'repaired' the lack-of-CLA failure above.

[cary-ilm]

LGTM, thanks!