Yeah, I would be cautious with default DPX metadata... we actually modify the
metadata to fit our needs when we publish images in the network.
Image Magik and RVIO would work fine for setting DPX tag values.
________________________________
From: Sam Cole <[email protected]>
To: Nuke user discussion <[email protected]>
Sent: Saturday, October 8, 2011 2:28 AM
Subject: Re: [Nuke-users] LUT global location, variable(s)???
I don't recall the software that wrote them in the past but I have a mistrust
of the metadata from DPX. We also do things like log/logc/panalog jpegs for
quick reviews where the file type or metadata might be misleading. We have the
colorspace in the filepath and set the transfer function in source_setup.mu
from a regex on that.
./sam
On 08/10/2011, at 11:27 AM, Torax Unga wrote:
Be careful when modifying the source_setup.mu file to interpret DPX files,
since they can come in a variety of colorspaces (Log, LogC, SLog, Rec709, etc)
>there is a couple of examples in that file that shows you how to read DPX
>metadata... this is the way we interpret DPX in Rv. I would reccomend using
>the "Transfer" tag to set the right interpretation.
>
>
>
>
>________________________________
>From: "[email protected]" <[email protected]>
>To: Nuke user discussion <[email protected]>
>Sent: Friday, October 7, 2011 10:09 AM
>Subject: Re: [Nuke-users] LUT global location, variable(s)???
>
>
>Yes, that is the module that you need to override. By setting RV_SUPPORT_PATH
>to a location of your choosing, and copying the same structure that the
>rvPackages file structure has, with an overriden source_setup.mu, you can
>change all behaviours. I think that even setting that file as empty will get
>rid of all colorspace assumptions.
>
>
>
>On Fri, Oct 7, 2011 at 9:35 AM, Jonathan Egstad <[email protected]> wrote:
>
>Yeah, we use RV to and I've already implemented the LUTs pulldown. Although I
>can't figure out how to force "No Conversion" when RV opens. The Alexa's auto
>default to DPX/Cineon.
>>>
>>
>>
>>You have to override the default colorspace handling code which is triggered
>>on a new-source event - I believe it's in the source_setup.mu' file.
>>
>>-jonathan
>>
>>
>>Thoughts?!
>>>
>>>Yeah, I'm feeling the same as you on FC too Nathan, although having that as
>>>a secondary is nice and it pisses me off to no end to not be able to figure
>>>this out or find a workaround.
>>>
>>>Thanks everyone!!!!!
>>>
>>>
>>>
>>>
>>>On Thu, Oct 6, 2011 at 7:09 PM, Nathan Rusch <[email protected]>
>>>wrote:
>>>
>>>Well, to be fair, FrameCycler is probably the black sheep in this
conversation... from what I can tell they just sort of do their own thing and
expect everyone to deal with it. Never once have I heard of them beta testing a
product or feature or asking for user feedback or input. Thus, my stance on
Framecycler has always been to steer away from it when things start to get
serious as far as maintaining any kind of a consistent, unified pipeline.
>>>>
>>>>Offhand, RV can actually do centralized configuration stuff even with local
installations (we use it that way). You can set up a default preferences file
in
a central location and point all users to it to start off with, and whichever
config file is newer (between the central and the user’s) will take precedence
in cases where a preference is defined in both. And obviously being able to
roll
your own extensions is a huge benefit for review tools, LUT repositories,
etc.
>>>>
>>>>-Nathan
>>>>
>>>>
>>>>From: Dan Walker
>>>>Sent: Thursday, October 06, 2011 10:52 AM
>>>>To: Nuke user discussion
>>>>Subject: Re: [Nuke-users] LUT global location,
variable(s)???
>>>> Not
too sure what else you were looking for really.
>>>>
>>>>
>>>>Being able to
control configuration settings on a piece of software (eg. FrameCycler) without
having to copy something to the software's native location (per machine).
>>>>
>>>>Nuke and RV can do it. RV is installed on our server and there are
env's you can set for custom lut locations. You can also modify the
User_settings.xml file that FC generates to hard code a path, but again, that
file is local to the machine FC is being ran on.
>>>>
>>>>
<LUTPath1>"\\xxx\xxx_xxx\release\nuke\config\project\XXX\versions\v001\nuke_LUT\"</LUTPath1>
>>>>
>>>>After
doing quiet a lot of research, I'm still stumped with FrameCycler. Yes
there are variables to control where framecycler puts it's temp files (which is
where the FrameCycler User_settings.xml also resides) but it's ridiculous to
assume, when defining a LUT setting for everyone, that you'll need to do it on
a
per machine basis.
>>>>
>>>>Yeah, it's great that there are software deployment
systems that can control the push of a config and all the other features that
comes with it, but come on! This isnt' the 90's for cry'in out loud. One
would think software has been developed to "assume" that a facility would maybe
want to have the feature of setting a "global" config and not assume all
facilities are interconnected when it comes to Pipeline and IT
departments. What about facilities that are global (meaning all around the
world) that reference a "cloud" server? Should I have to push a config to
all the users in London, Hong Kong, etc....
>>>>
>>>>My .02
>>>>
>>>>
>>>>
>>>>
>>>>On Tue, Oct 4, 2011 at 3:28 PM, Dave Goodbourn <[email protected]>
>>>>wrote:
>>>>
>>>>Now that all depends on your definition of quick! Once you have a software
>>>>distribution system setup, making any change to 100+ workstations and
>>>>render nodes can only take a matter of minutes!
>>>>>
>>>>>You can always do it with scripting to copy config files and setup
>>>>>variables on each machine. Not too sure what else you were looking for
>>>>>really.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>On 4 Oct 2011, at 23:07, Dan Walker <[email protected]> wrote:
>>>>>
>>>>>
>>>>>Wow, no quick solutions? That just sucks now don't it! :-)
>>>>>>On Oct 4, 2011 10:27 AM, "Dave Goodbourn" <[email protected]>
>>>>>>wrote:
>>>>>>> Have you looked at software deployment software like
WPKG <http://wpkg.org/> at
>>>>>>> all? You can very easily deploy all the settings and
environmental variables
>>>>>>> to all your machines from the comfort of
your own seat! Works well for us.
>>>>>>> It's only Windows based but
there's plenty of *nix solutions like
>>>>>>> Puppet<http://puppetlabs.com/>
>>>>>>> .
>>>>>>>
>>>>>>>
D.
>>>>>>>
>>>>>>> On Tue, Oct 4, 2011 at 6:12 PM, Dan Walker <[email protected]> wrote:
>>>>>>>
>>>>>>>> Hi
Torax,
>>>>>>>>
>>>>>>>> unfortunately software cannot be installed on
a server. even if it was you
>>>>>>>> would still have to setup each
individual artist with the manually defined
>>>>>>>> environment
variables or paths to the luts location. I'm specifically
>>>>>>>>
talking about frame cycler when manually defining paths. all nuke
software
>>>>>>>> is installed locally on each machine and I'm looking
for a way to point
>>>>>>>> frame cycler and rv at luts installed
globally. I'm wanting all of this done
>>>>>>>> without having to go to
each artist machine and perform a manual setup. Nuke
>>>>>>>> already has
a viewer lut setup, utilizing the alexa 3D lut through a vector
>>>>>>>>
field node.
>>>>>>>> On Oct 4, 2011 1:00 AM, "Torax Unga" <[email protected]> wrote:
>>>>>>>> > There are many different approaches:
>>>>>>>>
> Here is one:
>>>>>>>> > - you will probably want to have you
software installed in a central
>>>>>>>> location in the networks, so you
only modify the settings once
>>>>>>>> >
>>>>>>>> > - put the
luts in a location all software can see. (ie: ../luts/nuke/
>>>>>>>>
../framecycler ../rv)
>>>>>>>> > - generate the flavors of the lut for
the software (I recomend .csp for
>>>>>>>> Nuke and RV and .cube for
Framecycler)
>>>>>>>> > - you can assign environment variables to
those ( ie $NUKE_ALEXA_LUT)
>>>>>>>> >
>>>>>>>> > - for Nuke
create a viewer lut that point to the luts using the
>>>>>>>> Vectorfiled
node.
>>>>>>>> > - for RV you can download and install the "Custom
Luts Menu" package
>>>>>>>> available on their web site and modify the
scripts to point to the lut
>>>>>>>> location', and to assign a hot key
to it. you can also modify the "
>>>>>>>> sources.mu" file so the lut get applied automatically based on some
>>>>>>>> conditionals.
>>>>>>>> > - in framecycler
you can modify the lut search folder in the settings to
>>>>>>>> point to
your lut folder.
>>>>>>>> >
>>>>>>>> > there definitely more
advance setups, but this one should work.
>>>>>>>> >
>>>>>>>>
>
>>>>>>>> >
>>>>>>>> >
________________________________
>>>>>>>> > From: Dan Walker <[email protected]>
>>>>>>>> > To: Nuke user
discussion <[email protected]>
>>>>>>>> >
Sent: Monday, October 3, 2011 6:56 PM
>>>>>>>> > Subject: [Nuke-users]
LUT global location, variable(s)???
>>>>>>>> >
>>>>>>>>
>
>>>>>>>> > Hey,
>>>>>>>> >
>>>>>>>> > Anyone have a
quick setup for accessing LUT's in a global location that
>>>>>>>> RV,
FrameCycler and Nuke can access, upon execution of whatever Flipbook
app
>>>>>>>> you're using.
>>>>>>>> >
>>>>>>>> >
Example:
>>>>>>>> >
>>>>>>>> > I'm in Nuke - Nuke is using a
custom Alexa LUT as the viewer LUT
>>>>>>>> (referencing the nuke 3D LUT
at a global facility wide location)
>>>>>>>> >
>>>>>>>> > I
launch FrameCycler - I want to access a custom Alexa LUT
(referencing
>>>>>>>> the IRIDAS 3D LUT at a global facility wide
location)
>>>>>>>> >
>>>>>>>> > I launch RV - I want to access a
custom Alexa LUT (referencing a 3D LUT
>>>>>>>> at a global facility wide
location)
>>>>>>>> >
>>>>>>>> > I want all of this setup
globally instead of having to load the LUT's for
>>>>>>>> each flipbook
app on an individual basis.
>>>>>>>> >
>>>>>>>> > Thanks much in
advance!
>>>>>>>> >
>>>>>>>> > -Dan
>>>>>>>> >
>>>>>>>>
>
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
>>>>>>>> >
_______________________________________________
>>>>>>>> > 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
>>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> --
>>>>>>>
>>>>>>> *Dave Goodbourn***
>>>>>>>
>>>>>>> IT Manager
>>>>>>>
>>>>>>> **
>>>>>>>
>>>>>>> *
>>>>>>> *
>>>>>>>
>>>>>>> *uFX **(a division** of uMedia)*
>>>>>>>
>>>>>>> *UK: *2nd &
3rd Floors, 32 Rathbone Place, London, W1T 1JJ
>>>>>>>
>>>>>>> *BE: *Avenue
Louise 235, 1050 Brussels, Belgium
>>>>>>>
>>>>>>> *GENERAL *+44 20 7268 0068
>>>>>>>
>>>>>>> *FAX* +44 20 7268 0069
>>>>>>> [email protected]
>>>>>>>
>>>>>>> www.u-fx.co.uk
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> Confidentiality
>>>>>>> notice<http://www.umedia.eu/medias/CONFIDENTIALITY20NOTICE.pdf>
>>>>>>>
>>>>>>> Company legal
>>>>>>> information<http://www.umedia.eu/medias/Company_legal_information.pdf>
>>>>>>
>>>>>_______________________________________________
>>>>>>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
>>>>>
>>>>
>>>>
>>>>
>>>>________________________________
>>>>
>>>>_______________________________________________
>>>>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
>>>>
>>>_______________________________________________
>>>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
>>
>
>
>--
>Jose Fernandez de Castro
>
>_______________________________________________
>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
_______________________________________________
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
