I made a post a few weeks ago about the same black pixel problem
(random pixel read). I use the same nuke version and try to read a
single pixel with at() after a request()... This work with most pixels
except on some random rows...

Nicolas

Envoyé de mon iPhone

Le 25 mars 2011 à 18:42, Moritz Moeller <[email protected]> a écrit :

> We have a problem where we randomly get black pixels from upstream nodes
> we validate() and request() 'somewhere' deep in our engine().
>
> Basically we cannot know if we need to validate() (and subsequently
> request()) them by the time our own validate() method is ran by Nuke.
>
> We did not see this in the past, the resp. code has not changed in half
> a year.
> I'd dare say it feels like it may be related to us building/testing
> against 6.2v2 now.
> It doesn't matter what nodes are upstream. However, we only query Iops
> and Read nodes this way.
>
> Another thing is that is seems to be #-of-threads-related. I.e. on boxes
> with 8 cores it shows more than on boxes with 6 cores and on boxes with
> 2 cores we cannot replicate it at all (everything works as expected).
>
> Our code does only request rows serially though and doesn't use
> Row::start()/Row::wait() or anything like that; so the threading stuff
> is not on our side.
>
>
> A typical code fragment looks like this:
>
>    _node->validate( true );
>
>        unsigned short width( _node->info().width() );
>        unsigned short height( _node->info().height() );
>
>        ChannelSet channelMask( Mask_RGBA );
>        channelMask &= _node->info().channels();
>        unsigned channels( channelMask.size() );
>
>        _node->request( 0, 0, width, height, channelMask, 1 );
>
>        Row row( 0, width );
>
>        for ( unsigned scanLine( 0 ); scanLine < height; ++scanLine ) {
>
>            _node->get( scanLine, 0, width, channelMask, row );
>
>            foreach( channel, channelMask ) {
>                // read row[ channel ] and use somehow
>        }
>        }
>
>
>
> What am I missing here?
>
>
> .mm
>
> _______________________________________________
> Nuke-dev mailing list
> [email protected]
> http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev
_______________________________________________
Nuke-dev mailing list
[email protected]
http://support.thefoundry.co.uk/cgi-bin/mailman/listinfo/nuke-dev

Reply via email to