Re: [Openexr-devel] exr shake plugin bug

[Ken McGaugh]

There is a problem with the fix I just mailed out.
I think it will prevent the exr translator for being
able to output the shake DOD as the image's dataWindow.

So my latest solution for the empty DOD problem is to
catch it when computing the pOut->roi() and force an
roi that is 1 pixel.  So the constructor logic would
now look like:

    pOut->roi()->addDependencies(
        pOut->dod(),
        pOut->width(),
        pOut->height(),
        0
        );

And then in the eval() I'm doing:

        iRoi = pOut->getDod();
        if ( m_iRoi.X2 <= m_iRoi.X1 ||
             m_iRoi.Y2 <= m_iRoi.Y1 )
        {
            // This roi is empty and if used will cause no
            // file to be created.  So we force it in this
            // case to be one pixel.  Make that single pixel
            // be the upper-left one so that the exr dataWindow
            // will be (0,0)-(0,0).
            iRoi.X1 = 0;
            iRoi.X2 = 1;
            iRoi.Y2 = pOut->height()->asInt();
            iRoi.Y1 = iRoi.Y2 - 1;
        }
        p->set( &iRoi );

Sorry for the confusion.
--Ken


Ken McGaugh wrote:
> Hey all, I came across a bug in the sample sdk format
> plugin for shake which affects any file format translators
> derived from that code.  The bug is that if the frame you
> are rendering has a DOD completely outside the view no
> output file is created.
>
> Apple sent me a fix I'd like to pass along since it affects
> the OpenEXR format translator.  In the writer's constructor
> change dependency logic for the pOut->roi() plug to look like
>
>      pOut->roi()->addDependencies(
>          pOut->width(),
>          pOut->height(),
>          0
>          );
>
> Then in the eval() function modify the pOut->roi() logic to
> look like
>
>     else if (p == pOut->roi())
>     {
>         iRoi.X1 = 0;
>         iRoi.X2 = pOut->width()->asInt();
>         iRoi.Y1 = 0;
>         iRoi.Y2 = pOut->height()->asInt();
>
>         p->set(&iRoi);
>         }
>
> Note that I think the OpenEXR translator will still break in this
> situation since it will be passed an empty dataWindow.  In our
> translator we have to catch that situation explicitly and output
> a 1 black pixel dataWindow.
>
> --Ken
>
>
>
>
> _______________________________________________
> Openexr-devel mailing list
> address@hidden
> http://lists.nongnu.org/mailman/listinfo/openexr-devel