Re: [Nuke-users] LUT global location, variable(s)???
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" 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 > *To:* Nuke user discussion > *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:* "pixelcowbo...@gmail.com" > *To:* Nuke user discussion > *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 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 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. > > " > \\xxx\xxx_xxx\release\nuke\config\project\XXX\versions\v001\nuke_LUT\ > " > > 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 deve
Re: [Nuke-users] LUT global location, variable(s)???
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 To: Nuke user discussion 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: "pixelcowbo...@gmail.com" >To: Nuke user discussion >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 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 >>>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. "\\xxx\xxx_xxx\release\nuke\config\project\XXX\versions\v001\nuke_LUT\" 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 departm
Re: [Nuke-users] render settings
Simply typing "" also creates four digit frame padding. Example: filename..dpx (renders a sequence starting with "filename..dpx") There are days where I'm rendering many versions (and stages) especially when working with Paint strokes and shapes. And just having to use "#" makes life easier. Just my take. On Oct 8, 2011, at 8:45 AM, ari Rubenstein wrote: > Don't add the % after the d, should be : > > filename.%04d.tga > > Sent from my iPhone > > On Oct 8, 2011, at 11:24 AM, Mahesh Kumar > wrote: > >> hi all, >> >> I am confusing with render settings in Nuke write node, i want to render >> sequence images i created filename.%04d%.tga or png is it correct or is >> there any other names plz suggest me. >> >> cheers >> ___ >> Nuke-users mailing list >> Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ >> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > ___ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] recommended Linux
This is where it's important to also have a CentOS machine around, to replicate any issues before reporting them. I have yet to find a repeatable bug on our Ubuntu setup that has then worked smoothly without any issues on CentOS. Hugh Macdonald nvizible – VISUAL EFFECTS hugh.macdon...@nvizible.com +44(0) 20 3167 3860 +44(0) 7773 764 708 www.nvizible.com On 8 Oct 2011, at 11:37, John RA Benson wrote: > oops - dangit - that wasn't meant for the list. > > for the record, we did the same fix for suse 11. > > jrab > > > On Oct 8, 2011, at 12:32, John RA Benson > wrote: > >> aha - looks like the lib fix we did is normal - but see Peter Pearson's note >> at the end. >> >> jrab >> >> On Oct 7, 2011, at 17:32, Hugh Macdonald wrote: >> >>> For anyone going with Ubuntu, do be aware that the system has some newer >>> libraries that Nuke is shipped with... To get compiled plugins to run, I >>> had to move the following libraries out of the Nuke installation folder and >>> into an "old_libs" folder, to get Nuke and the plugins to use the system >>> libraries rather than the distributed libraries: >>> >>> libgcc_s.so.1 >>> libstdc++.so.6 >>> libstdc++.so.6.0.8 >>> >>> >>> This was only an issue when using plugins that had been compiled on that >>> Ubuntu machine. >>> >>> >>> Hugh Macdonald >>> nvizible – VISUAL EFFECTS >>> >>> hugh.macdon...@nvizible.com >>> +44(0) 20 3167 3860 >>> +44(0) 7773 764 708 >>> >>> www.nvizible.com >>> >>> On 7 Oct 2011, at 15:08, Joerg Bruemmer wrote: >>> Thanks guys! Am 07.10.2011 um 15:55 schrieb Holger Hummel|Celluloid VFX: > > http://vault.centos.org/5.4/isos/ > > > > > Joerg Bruemmer wrote: >> Hm, only can find Centos5.7 on their site >> Am 07.10.2011 um 15:28 schrieb Peter Pearson: >> >> >>> On 07/10/11 14:15, Joerg Bruemmer wrote: >>> Ok. Thanks. But when supporting RHEL why not Fedora? Any reason for that? Cheers, J. >>> Fedora's not officially supported by Red Hat, it's the community >>> version - it's normally used as the test-bed (stabilising tree) for >>> packages before they're put into the next RHEL version. >>> >>> You *should* be okay with anything from Ubuntu, Mint, CentOS, Fedora, >>> etc. >>> >>> But we only guarantee that Nuke is compatible with RHEL / CentOS 5.4 >>> (for 6.3 anyway) - if you end up have issues with libc/stdc++ version >>> incompatibilities, Xorg versions or custom kernel stuff due to the >>> distribution you use (in other words, crashes or weird behaviour that >>> we can't reproduce under RHEL 5.4), you're on your own. >>> >>> Peter >>> -- >>> Peter Pearson, Software Engineer >>> The Foundry, 6th Floor, The Communications Building, >>> 48 Leicester Square, London, UK, WC2H 7LT >>> Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk >>> >>> The Foundry Visionmongers Ltd. >>> Registered in England and Wales No: 4642027 >>> ___ > ___ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] render settings
Don't add the % after the d, should be : filename.%04d.tga Sent from my iPhone On Oct 8, 2011, at 11:24 AM, Mahesh Kumar wrote: > hi all, > > I am confusing with render settings in Nuke write node, i want to render > sequence images i created filename.%04d%.tga or png is it correct or is there > any other names plz suggest me. > > cheers > ___ > Nuke-users mailing list > Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
[Nuke-users] render settings
hi all, I am confusing with render settings in Nuke write node, i want to render sequence images i created filename.%04d%.tga or png is it correct or is there any other names plz suggest me. cheers___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] recommended Linux
oops - dangit - that wasn't meant for the list. for the record, we did the same fix for suse 11. jrab On Oct 8, 2011, at 12:32, John RA Benson wrote: > aha - looks like the lib fix we did is normal - but see Peter Pearson's note > at the end. > > jrab > > On Oct 7, 2011, at 17:32, Hugh Macdonald wrote: > >> For anyone going with Ubuntu, do be aware that the system has some newer >> libraries that Nuke is shipped with... To get compiled plugins to run, I had >> to move the following libraries out of the Nuke installation folder and into >> an "old_libs" folder, to get Nuke and the plugins to use the system >> libraries rather than the distributed libraries: >> >> libgcc_s.so.1 >> libstdc++.so.6 >> libstdc++.so.6.0.8 >> >> >> This was only an issue when using plugins that had been compiled on that >> Ubuntu machine. >> >> >> Hugh Macdonald >> nvizible – VISUAL EFFECTS >> >> hugh.macdon...@nvizible.com >> +44(0) 20 3167 3860 >> +44(0) 7773 764 708 >> >> www.nvizible.com >> >> On 7 Oct 2011, at 15:08, Joerg Bruemmer wrote: >> >>> Thanks guys! >>> >>> Am 07.10.2011 um 15:55 schrieb Holger Hummel|Celluloid VFX: >>> http://vault.centos.org/5.4/isos/ Joerg Bruemmer wrote: > Hm, only can find Centos5.7 on their site > Am 07.10.2011 um 15:28 schrieb Peter Pearson: > > >> On 07/10/11 14:15, Joerg Bruemmer wrote: >> >>> Ok. Thanks. But when supporting RHEL why not Fedora? Any reason for >>> that? >>> Cheers, >>> J. >>> >> Fedora's not officially supported by Red Hat, it's the community version >> - it's normally used as the test-bed (stabilising tree) for packages >> before they're put into the next RHEL version. >> >> You *should* be okay with anything from Ubuntu, Mint, CentOS, Fedora, >> etc. >> >> But we only guarantee that Nuke is compatible with RHEL / CentOS 5.4 >> (for 6.3 anyway) - if you end up have issues with libc/stdc++ version >> incompatibilities, Xorg versions or custom kernel stuff due to the >> distribution you use (in other words, crashes or weird behaviour that we >> can't reproduce under RHEL 5.4), you're on your own. >> >> Peter >> -- >> Peter Pearson, Software Engineer >> The Foundry, 6th Floor, The Communications Building, >> 48 Leicester Square, London, UK, WC2H 7LT >> Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk >> >> The Foundry Visionmongers Ltd. >> Registered in England and Wales No: 4642027 >> ___ ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
Re: [Nuke-users] recommended Linux
aha - looks like the lib fix we did is normal - but see Peter Pearson's note at the end. jrab On Oct 7, 2011, at 17:32, Hugh Macdonald wrote: > For anyone going with Ubuntu, do be aware that the system has some newer > libraries that Nuke is shipped with... To get compiled plugins to run, I had > to move the following libraries out of the Nuke installation folder and into > an "old_libs" folder, to get Nuke and the plugins to use the system libraries > rather than the distributed libraries: > > libgcc_s.so.1 > libstdc++.so.6 > libstdc++.so.6.0.8 > > > This was only an issue when using plugins that had been compiled on that > Ubuntu machine. > > > Hugh Macdonald > nvizible – VISUAL EFFECTS > > hugh.macdon...@nvizible.com > +44(0) 20 3167 3860 > +44(0) 7773 764 708 > > www.nvizible.com > > On 7 Oct 2011, at 15:08, Joerg Bruemmer wrote: > >> Thanks guys! >> >> Am 07.10.2011 um 15:55 schrieb Holger Hummel|Celluloid VFX: >> >>> >>> http://vault.centos.org/5.4/isos/ >>> >>> >>> >>> >>> Joerg Bruemmer wrote: Hm, only can find Centos5.7 on their site Am 07.10.2011 um 15:28 schrieb Peter Pearson: > On 07/10/11 14:15, Joerg Bruemmer wrote: > >> Ok. Thanks. But when supporting RHEL why not Fedora? Any reason for that? >> Cheers, >> J. >> > Fedora's not officially supported by Red Hat, it's the community version > - it's normally used as the test-bed (stabilising tree) for packages > before they're put into the next RHEL version. > > You *should* be okay with anything from Ubuntu, Mint, CentOS, Fedora, etc. > > But we only guarantee that Nuke is compatible with RHEL / CentOS 5.4 (for > 6.3 anyway) - if you end up have issues with libc/stdc++ version > incompatibilities, Xorg versions or custom kernel stuff due to the > distribution you use (in other words, crashes or weird behaviour that we > can't reproduce under RHEL 5.4), you're on your own. > > Peter > -- > Peter Pearson, Software Engineer > The Foundry, 6th Floor, The Communications Building, > 48 Leicester Square, London, UK, WC2H 7LT > Tel: +44 (0)20 7434 0449 Web: www.thefoundry.co.uk > > The Foundry Visionmongers Ltd. > Registered in England and Wales No: 4642027 > ___ ___ Nuke-users mailing list Nuke-users@support.thefoundry.co.uk, http://forums.thefoundry.co.uk/ http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users
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: "pixelcowbo...@gmail.com" > To: Nuke user discussion > 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 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 >> 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. >> >> >> "\\xxx\xxx_xxx\release\nuke\config\project\XXX\versions\v001\nuke_LUT\" >> >> 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 >> wrote: >> Now that all depends on your definition of quick! Once you have a software >> distri
