fix!(adaptor): Fix OCIO adaptor while baking. - #517
Conversation
github-actions
Bot
added
the
waiting-on-maintainers
Signed-off-by: Karthik Bekal Pattathana <133984042+karthikbekalp@users.noreply.github.com>
![github-actions[bot]](https://avatars.githubusercontent.com/in/15368?s=60&v=4){kind=small}
| # and restores this flag in finalize_tile_render. | ||
| orig_bake_flag = self.render_data[c4d.RDATA_BAKE_OCIO_VIEW_TRANSFORM_RENDER] | ||
| self.render_data[c4d.RDATA_BAKE_OCIO_VIEW_TRANSFORM_RENDER] = False | ||
| orig_bake_flag = rd.GetBool(c4d.RDATA_BAKE_OCIO_VIEW_TRANSFORM_RENDER) |
There was a problem hiding this comment.
BaseContainer.GetBool(id) silently defaults to False when the id is not present in the container, so the "original" value we capture here is not necessarily the value C4D was actually using.
RDATA_BAKE_OCIO_VIEW_TRANSFORM_RENDER was added in 2025.2, and a render data container deserialized from an older scene (or one where the parameter has never been explicitly touched) may not carry an entry for it — in that case C4D falls back to the description default while GetBool here returns False. The finally block then writes False back into the container, which is a change, not a restore: the flag is now explicitly disabled on the shared self.render_data for the rest of the session (the comment above notes the document is reused across renders).
The subsequent 8-bit non-tile renders re-enter this branch and bake manually, so beauty output stays correct, but a later render in the same session that relies on the render-time bake — e.g. a 16-bit output, which bake_ocio excludes at line 339 and therefore never bakes manually — would come out un-tone-mapped where it previously was not.
Two ways to make the save/restore faithful:
- Only restore when the parameter was actually present, e.g. capture
had_flag = rd.GetType(c4d.RDATA_BAKE_OCIO_VIEW_TRANSFORM_RENDER) != 0alongside the value and skip the write-back (orrd.RemoveData(...)) when it was absent. - Or read through the RenderData object so the description default is honoured, and pass an explicit preset matching that default rather than relying on
GetBool's implicitFalse.
Note the same pattern exists in tile_rendering.setup_tile_render (line 195), so whichever fix is chosen is probably worth applying in both places for consistency.
2 participants
What was the problem/requirement? (What/Why)
This PR introduced few changes :
What was the solution? (How)
As this has potential to break customers expected color profile, marking this commit as backwards incompatible so that it bumps the version number.
The tests were failing with the error, so this would have failed the renders as well.
What is the impact of this change?
This will fix the render output issue for the tests.
How was this change tested?
Have you run the unit tests?
Yes
Have you run the integration tests? (Add your integration test report below)
Yes and it passes: https://github.com/aws-deadline/deadline-cloud-for-cinema-4d/actions/runs/31440614832/job/93624348257
No
Was this change documented?
Yes
Is this a breaking change?
Yes, customers who want the old non OCIO behavior need to use the older
0.11.*version.By submitting this pull request, I confirm that you can use, modify, copy, and redistribute this contribution, under the terms of your choice.