Yeah - it's that Nuke's reader currently only supports scanline EXR 2.0 (which is better for Nuke anyway). It's advantageous to convert from dtex to EXR2 because of other cost savings anyway, and the conversion from the intrinsically bucket-oriented dtex to a Nuke-friendly scanline approach speeds things up even more.
On Sat, Aug 3, 2013 at 8:29 PM, Larry Gritz <l...@larrygritz.com> wrote: > Maybe it's my misunderstanding, but at the "deep comp BOF" (which I really > thought you were at) people were saying that they had to output dtex and > then separately convert to OpenEXR 2.0, because of OpenEXR bugs related to > outputting deep tiles. > > Did I misunderstand the situation? > > > On Aug 3, 2013, at 4:31 PM, Piotr Stanczyk wrote: > > > really? I wasn't aware / there. > > > > This is the only one I could find- which i think should be fixed > > https://github.com/openexr/openexr/pull/62 > > > > - Piotr > > > > -- > Larry Gritz > l...@larrygritz.com > > > > _______________________________________________ > Openexr-devel mailing list > Openexr-devel@nongnu.org > https://lists.nongnu.org/mailman/listinfo/openexr-devel > -- I think this situation absolutely requires that a really futile and stupid gesture be done on somebody's part. And we're just the guys to do it.
_______________________________________________ Openexr-devel mailing list Openexr-devel@nongnu.org https://lists.nongnu.org/mailman/listinfo/openexr-devel