> 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
