I know it will sound inappropriate and semi-arrogant (and of course it IS after all an issue in Nuke that it has no support for TIFF metadata, yes) but just to recap:
- you are having sour frames in your render - the likely problem is some machine which has corrupt RAM sticks (we've had this) or network filesystem issue/congestion - you refuse to use a format which allows the tagging you are using natively (not going EXR and not going DPX) - you know that your renders rot due to one issue or another, it creates problems for the facility - and yet something as basic as logging frameranges per render packet is not possible. What is your sys then, an Exchange administrator having cocktails while your renders go south? If there is a render node that corrupts renders it's all hands on deck if management is at least semi-reasonable, since it's everyone's priority at that stage to isolate that node and reevaluate it's components - you resort to having to install some weird header baking CLI application that you will need to configure, compile, script and check it's security (you are shelling out in there...), and that either through your whole deployment pipe or per machine (depending on how good and lazy your sys is). That instead of first baking the EXRs and then simply converting them into the TIFFs you need (using an after render Nuke commandline call)? (whats the reason for TIF in the first place? are TIFFs needed for paint apps? are they your deliverable? sure you want to cut off headroom color if your frame takes so long)? Looks like you painting yourself into a corner, meanwhile looking for smarter and smarter ways to do it. On a recent project where we had an EXR pipeline we've made a gizmo that renders JPEGs with burnin together with the EXRs, and the EXRs also had the metadata in them as to which node that was, which script and so on. For node data on renders, we've picked this into our init: import os, socket os.environ["HOSTNAME"] = socket.gethostname() and then for the burnin message: Script: [value root.cachedscriptname] TC: [metadata "exr/TimeCode"] Rendered: [date %d.%m.%Y] Frame: [format "%04d" [frame]] of: [value lastf] RenderNode: [getenv HOSTNAME] In our tests the EXR render always went on the same node as the JPEG. On 30 jan. 2013, at 12:11, Diogo Girondi <[email protected]> wrote: > Metadata for sure is always nice, and if TIFF files wasn't a mandatory thing > in this case using EXR files would allow for a easy fix for this problem. -- Julik Tarkhanov | HecticElectric | Keizersgracht 736 1017 EX Amsterdam | The Netherlands | tel. +31 20 330 8250 cel. +31 61 145 06 36 | http://hecticelectric.nl
smime.p7s
Description: S/MIME cryptographic signature
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
