Yeah all kind of data is missing in plates we get back from various vendors. Curious why you don't use nuke to incorporate important info back into published images. On Oct 8, 2011 2:30 PM, "Torax Unga" <[email protected]> wrote:
> 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 <[email protected]> > *Sent:* Thursday, October 06, 2011 10:52 AM > *To:* Nuke user discussion <[email protected]> > *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 >
_______________________________________________ Nuke-users mailing list [email protected], http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
