This I wholeheartedly agree on. Often specifications directly contradict themselves too. I get the feeling that a lot of them are copied and pasted from multiple sources.
I guess it would be hard for someone writing a spec to leave themselves open to being challenged about any compromises on quality. It would be much easier to set a spec insisting on shooting RAW codecs only and all post production would need to use mathematically lossless codecs then saying, if the cinematographer knows what they are doing then shooting ProRes4444 will suffice or that post production can use visually lossless compression as long as the end result isnāt visually compromised.
How good would it be if production budgets were taken into account in regards to specifications. Most folks on here doing TVCs wonāt have these issues but those of us working on longform certainly do
Just for interest: been using DWAA for 5+years. Got the mill London to convert to this before I left. PIZ was the preferred choice but playback of them in Nuke was noticeably slower.
So we used DWAA for the majority of commercials.
There will always be the odd case with super strict QC depts that wonāt permit this workflow.
I have thought about it a lot and DWAA & DWAB compression just makes so much sense as a working format. Iāve tried to push some grades hard compared to PIZ and they are visually lossless. I cannot see any artefacts or banding or anything that would create issues.
Using exr to transport log colour spaces is much more damaging than the level of compression DWA introduces.
Please give this a go and let us know how things go:
You can customize the cache & render formats using the stone+wire.cfg file. In the DefaultFileFormats section, just define this:
-find the following line:
#floatVideo=RAW
-Remove the # sign
-Define your custom float cache format (see list of supported compressions in the section)
floatVideo=EXR:DWAA
Save the file, restart Flame and when Creating or Modifying an existing project, select Cache & Renders / Legacy Configuration and you will see that the 16 & 32-bit fp format are now set to OpenEXR(DWAA).
cool yea I would obviously love to have DWAB or ProRes also as a option for 8/10/12 bit files while its not the technically BEST way to handle things it should be a option.
We will need to design a way to have a high precision mode for when we are given STMaps or WorldPossition, for example. Where DWA compression might negatively effect those passes.
It is tricky to solve this scenario. Especially if those passes get provided in a multi channel EXR
We work almost entirely in ProRes and DWA but still use PIZ for our UVs or motion vectors we pre render.
I cache all media that I pull in from our server. Multichannel EXRs from CG run like butter if I cache but can be subject to slowdown, when our server is busy, if I do not.
I would like it to be a little bit like colourMgt. We can have a set of rules that are customisable but also over ridden if needed to.
Couldnāt you just write your lossless exr files to the same volume your framestore resides on? Then there is no difference between cacheing a Piz or reading it.
thats pretty much why we went full lucid-link you just get all media from your nas as if it was cached, thats huge for us especially with heavy CG renders and especially in nuke.
i feel that pain, in this case i would probably just leave it all cache wise to piz and just render stuff as dwab to the nas.
for me dwab is great becaue i read my cache from a nas woth just 10Gbit. so its flipped for me, footage is local but cache is on a server.
Just finished work on a show that used HDE arriraw. Looked horribly compressed. Asked the rental shop that delivered the cameras, dailies, conform and vfx pulls if they could check their pipeline. Response was that the arriraws matched the EXRs delivered, so with my limited knowledge of HDE, Iād be hesitant to recommend using it.
HDE is losless compressed its bit for bit identical to arriraw, there is no difference at all, absolutely zero.
its just like running zip compression over a word document ā¦
this sounds like something went horrible somewhere but it cant be HDE.
the only downside with HDE is increased computationa as you have to uncompress it first, just like you do with R3D.
