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
