Rework HTML slate renderer.

[robin-ynput]

Changelog Description

Addresses the TODOs for HTML slate renderer:

• Turn generator and renderer as regular python classes and not dataclasses anymore
• Add unit tests

Changed behavior:

• Renderer will now raise a ValueError by default if the provided data does not fill up all of the expected template field
• Slate can ignore missing data and still goes through with the newly added SlateFillMode.HIDE_FIELD_WHEN_MISSING mode
• Provide default data for resolution, date and input frame range

Additional info

Contributes to #26
Depends on #30

Testing notes:

1. New automated tests have been added under tests/test_renderers_slate.py
2. Either use poetry or we can directly run helper .\start.ps1 test (Windows only)

[maxpareschi]

I've been following this a bit and just wanted to chime in on something that was marked to change:

"Renderer will now raise a ValueError if the provided data does not fill up all of the expected template field (instead of silently hidding them)"

The way we thought about it is that whenever there is a property that is not resolved we sub that prop with a specific string. That string becomes an identifier that is able to then hide the parent container if the info is not present. This is due to the fact that sometimes clients ask for very informative slates, but not always do we have data to show.
So what happens is that we just hide the row instead of

• not rendering the info but keeping the caption.
• failing.

If raising ValueError could be default behaviour but could be also opted out in favor of a workflow like that it would be most helpful. We do rely on a mechanism like that to hide and make the slates not crash most of the time in house.

As its is you are making the assumption that whoever fills the data

1. always have it.
2. always fills it up.

which is never the case in our experience, and Raising generates a lot of requests for pipe dept to fix things asap :)

[robin-ynput]

I've been following this a bit and just wanted to chime in on something that was marked to change:

"Renderer will now raise a ValueError if the provided data does not fill up all of the expected template field (instead of silently hidding them)"

The way we thought about it is that whenever there is a property that is not resolved we sub that prop with a specific string. That string becomes an identifier that is able to then hide the parent container if the info is not present. This is due to the fact that sometimes clients ask for very informative slates, but not always do we have data to show. So what happens is that we just hide the row instead of

• not rendering the info but keeping the caption.
• failing.

If raising ValueError could be default behaviour but could be also opted out in favor of a workflow like that it would be most helpful. We do rely on a mechanism like that to hide and make the slates not crash most of the time in house.

As its is you are making the assumption that whoever fills the data

1. always have it.
2. always fills it up.

which is never the case in our experience, and Raising generates a lot of requests for pipe dept to fix things asap :)

Thanks a lot @maxpareschi for the user/experience feedback, definitely most valuable.
I get your point and actually considered adding these "modes" as a future iteration.

All things considered, maybe I should actually go ahead and implement it right now.

EDIT: Just added a slate_fill_mode enum to the SlateHtmlGenerator to control this.

[jakubjezek001]

Lets implement the fixture from tests\conftest.py for test_staging_dir please.

[jakubjezek001]

Also it would be great for later test result analyses if each of test case would output into its own folder.

[robin-ynput]

Just to be sure this is what you had in mind.

I've adjusted this fixture to leverage the conftest.py/test_staging_dir one, for each test it will create a dedicated folder specific for this test and copy the resource sequence files over (so we can test the default prepend slate destination behavior). At the end of the test session test_staging_dir is deleted which cleans everything.

This way we ensure each test result is scoped .

[jakubjezek001]

Not sure where is this coming from but my results are produced following results.

BLD_010_0010_plateMain_v000.1000.exr.zip

[robin-ynput]

Not sure where is this coming from but my results are produced following results.

BLD_010_0010_plateMain_v000.1000.exr.zip

@jakubjezek001

Thanks for the material, this is very puzzling... Is this happening for all tests or just this one ?
I cannot reproduce this issue on my machine (Linux nor Windows) nor on the GH actions host..

From the screenshot, you can see:

• in green the burnins computed from the provided resolution (which confirms 1920x1080 is properly requested to selenium)
• in blue the output resolution which comes out of selenium screen save

I had a look at the selenium reported issues on the repo but I could not find anything meaningful.
My guess is that it could comes from weird selenium window.outerWidth, window.innerWidth, window.outerHeight, window.innerHeight which would result in a wrong output screen resolution there.

Out of curiosity, would it be please possible to run the test on your side and confirm which values you obtain for those ?

In the meantime, I have also added an additional -resize in the final oiio command line to ensure final resolution.
I'm not super found of it but this should fixes the tests on your side. Can you please confirm ?

Honestly, this looks more a patch than a proper required thing here.. but I couldn't think of anything better.

@tweak-wtf by any chance, would you also be able to please run the tests on this branch on your machine ? Would help a lot.

[tweak-wtf]

my tests say let's go.

i noticed that the output directories are named after the temp dirs they're coming from. don't know if that's intended but it makes it a bit difficult to know which test run produced them. there's also 2 output.exrs that i can't really map to something.

here's a screen of a slate on my potato:

scrubbing through some slated sequences i noticed that the slates seem to be always smaller than the plates.
checking with resolve and djv for all slate related test result folders for resolutions i get:

• for the 2 output.exrs:
  • resolve: 1920x1080
  • djv:
• for all others
  • resolve: 4382x2310
  • djv: pretty different, some 1920x1080 some 4096x2048

i'd suggest to get some nice informative directory names so we can track this down better

but slates do be rendered 🥳

[tweak-wtf]

OT: i probably should set something up where we can download latest produced test result from the GH actions. could be attestations right?

[robin-ynput]

Awesome, well I do like your suggestion. I've ensured that directory names now match test name.
This way it's now easier to troubleshoots result.

The result and resolution you got in Resolve match what I expected so I think we are good.
(I'm quite sure djv flags the higher resolution of the sequence).

That brings another question on my side, for now , unless explicitly provided, the slate resolution is HD-1080p.
That's what the existing code was doing on purpose, but maybe it makes more sense to adjust that to be the same resolution as the first frame of the input sequence ? What do you guys think ?

[tweak-wtf]

That brings another question on my side, for now , unless explicitly provided, the slate resolution is HD-1080p. That's what the existing code was doing on purpose, but maybe it makes more sense to adjust that to be the same resolution as the first frame of the input sequence ? What do you guys think ?

defaulting to 1920x1080 feels fine to me.
in my monkey brain these are 2 different use cases. i'll just refer to them as slate_only and prepend_to_sequence.
in slate_only u'd want to specify an explicit resolution, in prepend_to_sequence i'd assume the slate to be generated following the sequence's resolution.

[jakubjezek001]

Here are the resolution results I printed from line 256 in LabLib/lablib/generators/slate_html.py. I checked my virtual environment, and Selenium is version 4.16.0 on Windows, as defined in pyproject.toml. What versions do you have, @tweak-wtf and @robin-ynput ?

• test_Slaterenderer_missing_keys_hide: size [2459, 1859]
• test_Slaterenderer_default: size [2459, 1859]
• test_Slaterenderer_4K: size [4635, 2827]
• test_Slaterenderer_explicit_output: size [2459, 1859]

The resulting resolutions seem to be off. In the example image, the output from test_Slaterenderer_default should be 1920x1080, but it's coming out as 2459x1859.

There's also an issue with the broken template. This might be caused by the miscalculation, which then affects other calculations. Here is the original template look and the resulting look.

[maxpareschi]

Just to tell you that chrome in the —headless=new mode has two “bugs” (which apparently they are intended behavior but still)

• the viewport will always contain the interface elements, so you need to make the slate bigger and then crop it
• it you are using a hidpi monitor it’s going to screw up calculations. I’ve tried compensating with scale values but to no avail. You can try render slates again by setting the display scale size in windows or o 100%, this gave consistent results in our tests.
• If you are stuck in that you could always use —headless=old and revert to the normal behavior, still I did not test that with hidpi.

[robin-ynput]

Thanks a lot @maxpareschi, thanks to you I think I found something.

I played a bit with the Hight DPI / scale options in Windows and could reproduce a resolution mismatch (see scale 150%).

I've managed to fix this introducing a --force-device-scale-factor=1 to Chrome, so I've removed my unecessary oiio resize at the end.

To me, even with 125% or 150% set, the resulting HD and 4K slates matches the expected resolution and visual (selenium-0.4.16).

@jakubjezek001 does it fix the issue on your end as well ?

[tweak-wtf]

my environment is:

• selenium 4.16.0
• windows display scale: 125%
• windows display resolution: 2256x1504

i threw all slated sequences into resolve and made a screencast.
kinda misused the shot and scene here to refer to the test case name and the files resolution

from this i noticed:

• slate templates seem to be applied correctly now however, all slates seem to deviate from the 4k one in terms of aspect ratio.
  • it's noticeable better side by side
• seems there's a bug in the timecode offset. it should follow the sequence's start tc except the output.exr oc

[tweak-wtf]

jop the timecode issue i noted is only spotted now since spending some love on the slates.
played around a bit and for me this simple refactor actually did the trick lol.

Suggested change

	f"""'{timecode.replace('"', "")}'""",
	timecode,

[jakubjezek001]

I can confirm that this is fixing the issue.

[jakubjezek001]

Tested and all works fine now. @robin-ynput perfect!

Yeah the timecode issue is its own PR scope @tweak-wtf what do you thing. But could be added here if you found it important to include it.

[tweak-wtf]

Yeah the timecode issue is its own PR scope @tweak-wtf what do you thing. But could be added here if you found it important to include it.

cococool! i do think it's important that the TC is consistent but yeah probably a different PR. lemme go ahead on this

[tweak-wtf]

let's gooo 🚀