Re: [Nuke-users] Tiff metadata / tags

[John RA Benson]

while i appreciate everone's help, you pegged it: your response is sort of inappropriate and semi-arrogant. This thread concerns accessing a basic function that I figured nuke was capable of: metadata/tagging in a tiff format. the reasons are really irrelevant, but I provided them to help people understand why I was looking for it. I don't know why this thread turned into a pipeline / file format / sys admin attack. # We aren't having sour frames, we are having an occasionally erratic farm issue. Any ability to help with forensics is welcome. Heck, this could have been caused by fx loading the network and nothing to do with comp renders. Our sys guys aren't having cocktails. Formats and render managers are not something that is willy nilly decided and changed on the fly. I personally don't like tiff either, but that's our delivery format until exr's can be delivered, so that's that. We used to render exr and convert, but why bother doubling (yeah, I know, not quite) storage requirements and recheck everything twice? It's nice to deliver the frames that are rendered and not have to re-check conversions. I'm curious now if there is any render time difference between tiff and exr and then converting like we used to. On the surface, it's an extra process and overhead on the net, but if Nuke has a harder time with tiff and is actually making renders slower, that could be a huge deal and reason to switch back. But that's a different thread. Cheers JRAB On 01/30/2013 01:24 PM, Julik Tarkhanov wrote: 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 <diogogiro...@gmail.com> 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 _______________________________________________ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users

_______________________________________________
Nuke-users mailing list
Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users