My tests show that 4444 by itself shouldn't produce these large-block artefacts
What is the workflow? Are you decoding the QT directly in Nuke or is it converted in-between. Which platform and quicktime version etc. On 30 March 2013 05:43, Howard Jones <[email protected]> wrote: > It was the same here - shot directly in ProRes 444. > No idea what though > > > Howard > > ------------------------------ > *From:* Igor Majdandzic <[email protected]> > *To:* 'Nuke user discussion' <[email protected]> > *Sent:* Friday, 29 March 2013, 16:29 > *Subject:* AW: AW: [Nuke-users] Alexa Artifacts > > Do you know what caused them? > > -- > igor majdandzic > compositor | > [email protected] > BadgerFX | www.badgerfx.com > > *Von:* [email protected] [mailto: > [email protected]] *Im Auftrag von *Magno Borgo > *Gesendet:* Freitag, 29. März 2013 14:06 > *An:* Nuke user discussion > *Betreff:* Re: AW: [Nuke-users] Alexa Artifacts > > I've seen the exactly same artifacts when working on a film shot on Alexa. > These are nasty specially when keying... same issue, shot directly in > Proress 4444. > > Magno. > > > > > We've been having some problems with noise on some footages from Alexa, > but nothing remotely near to that. > > diogo > > On Wed, Mar 27, 2013 at 9:50 PM, Jonathan Egstad <[email protected]> > wrote: > No idea, but it looks an awful lot like filtering from a slight resize > operation. > > -jonathan > > On Mar 27, 2013, at 5:29 PM, "Igor Majdandzic" <[email protected]> > wrote: > > do you mean in camera? because that was from the original qt footage > > -- > igor majdandzic > compositor | > [email protected] > BadgerFX | www.badgerfx.com > > *Von:* [email protected] [mailto: > [email protected]] *Im Auftrag von *Jonathan > Egstad > *Gesendet:* Donnerstag, 28. März 2013 01:10 > *An:* Nuke user discussion > *Cc:* Nuke user discussion > *Betreff:* Re: [Nuke-users] Alexa Artifacts > > Looks like a very slight resize was done. > -jonathan > > On Mar 27, 2013, at 4:56 PM, "Igor Majdandzic" <[email protected]> > wrote: > > Hey guys, > we got footage from a shoot with Alexa being the camera. It was shot in > ProRess 444. The problem is: The picture has some artifacts which confuse > me the codec being 444. I attached some images which show some of the grain > patterns. Is this normal? > > thx, > Igor > > > > -- > igor majdandzic > compositor | > [email protected] > BadgerFX | www.badgerfx.com > > *Von:* [email protected] [ > mailto:[email protected]<[email protected]>] > *Im Auftrag von *Deke Kincaid > *Gesendet:* Mittwoch, 27. März 2013 23:47 > *An:* Nuke user discussion > *Betreff:* Re: [Nuke-users] FusionI/O and Nuke > > Hi Michael > I'm actually testing this right now as Fusionio just gave us a bunch of > them. Early tests reveal that with dpx it's awesome but with openexr zip > compressed file it it is spending more time with compression, not sure if > it is cpu bound or what(needs more study but its slower). Openexr > uncompressed files though are considerably superfast but of course the > issue is that it is 18 meg a frame. These are single layer rgba exr files. > > ----- > Deke Kincaid > Creative Specialist > The Foundry > Mobile: (310) 883 4313 > Tel: (310) 399 4555 - Fax: (310) 450 4516 > > The Foundry Visionmongers Ltd. > Registered in England and Wales No: 4642027 > > On Wed, Mar 27, 2013 at 3:26 PM, Michael Garrett <[email protected]> > wrote: > I'm evaluating one of these at the moment and am interested to know if > others have got it working with Nuke nicely, meaning, have you been able to > really utilise the insane bandwidth of this card to massively accelerate > any part of your day to day compositing? > > So far, I've found it has no benefit when localising all Reads in a > somewhat heavy comp, or even playing back a sequence of exr's or deep > files, compared to localised sequences on a 10K Raptor drive also in my > workstation - hopefully I'm missing something big though, this is day one > after all. > > There may be real tangible benefits to putting the Nuke cache on it though > - I'll see how it goes. > > I'm also guessing that as gpu processing becomes more prevalent in Nuke > that we will see a real speed advantage handing data from a card like this > straight to the gpu. > > Thanks, > Michael > > _______________________________________________ > Nuke-users mailing list > [email protected], http://forums.thefoundry.co.uk/ > http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-users > > > <crop-plate.jpg> > > <crop-plate_areas.jpg> > > <crop-plate_areas-edgeDetect.jpg> > > _______________________________________________ > 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 > > > > > -- > Magno Borgo > www.boundaryvfx.com > www.borgo.tv > Brasil:Curitiba:GMT= -3 > > _______________________________________________ > 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
