I think the tiff writer's lack of EXIF support has more to do with libtiff not supporting the writing of EXIF tags - it does supports the reading of them however.
So adding EXIF output support is probably a pretty heavy lift without libtiff's help... -jonathan On Feb 1, 2013, at 12:33 AM, Ben Dickson wrote: > > This thread concerns accessing a basic function that I figured nuke > > was capable of: metadata/tagging in a tiff format. > > As you found out, the tiffWriter doesn't write any of Nuke's extra metatdata. > > Based on > http://stackoverflow.com/a/13455695 > ...I would guess the reason is: the TIFF format doesn't support arbitrary > metadata keys, you can only use the keys defined by the EXIF spec: > > http://www.sno.phy.queensu.ca/~phil/exiftool/TagNames/EXIF.html > > Whereas the OpenEXR metadata can store any arbitrary keys (e.g you can have a > string property named "blahblahblah", and it'll work fine) > > So, when the tiffWriter was written there was a choice between either: > > 1. Writing only valid metadata keys into the TIFF, and somehow dealing with > unsupported keys and non-string values (which would probably be confusing for > users, however it's done) > 2. Don't write extra TIFF metadata. > > Option 2 is far easier, and less chance for surprise. > > You could email The Foundry support and request the code for the tiffWriter, > and easily modify it to write the hostname attribute (the tiffReader.cpp is > included in the NDK examples, so the writer shouldn't be a problem) > > ..but that's more work to achieve almost the same thing as using the > afterRenderCallback to modifying the EXIF headers > > On 31/01/13 04:01, John RA Benson wrote: >> 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 <[email protected] >>> <mailto:[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 >>> >>> >>> >>> _______________________________________________ >>> Nuke-users mailing list >>> [email protected],http://forums.thefoundry.co.uk/ >>> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users >> >> >> _______________________________________________ >> Nuke-users mailing list >> [email protected], http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > -- > ben dickson > 2D TD | [email protected] > rising sun pictures | www.rsp.com.au > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users _______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
