No, but it doesn't agree after all! When I instruct oiiotool to write an OpenEXR with pixel aspect of 2.0, Nuke correctly displays it as wide.
Same with TIFF. But when oiiotool writes a JPEG with pixel aspect of 2.0 -- I *THINK* I'm doing it right, there is no JPEG aspect field, in infers it from the x and y densities (pixels per inch), so I set ydensity = aspect*xdensity -- then Nuke displays it as as skinny rather than wide. Apparently, PhotoShop, rv, and ffmpeg all agree with Nuke. So it must be me who is wrong here! But for the life of me, I can't figure out from the JFIF spec why the Nuke/rv/ffmpeg/PS interpretation makes sense. Either the problem is entirely in my head -- I'm just interpreting the JFIF spec incorrectly -- or else a long time ago somebody got it backwards, and now everybody else is just trying to be compatible despite not agreeing with the spec. > On May 19, 2016, at 1:17 PM, Jonathan Egstad <[email protected]> wrote: > > (typing on a small iphone atm so I'll check out the thread in more detail > later) > > You're correct about what Nuke's format.pixel_aspect() is - it's the > correction factor from pixel-storage to real-world coordinates. > So a Nuke format with pa 2.0 is typically an anamorphic image where the > stored pixels are half their real-world width and require stretching out > horizontally when viewed. > > As for the jpeg reader/writer I wrote a pa 2.0 checkerboard jpeg out of Nuke > and it displays correctly in ffmpeg's ffplay viewer - i.e. not squished. > For reference DWA's internal viewing tool ignores the density vars and > displays a squished image. > > So I think you're interpretation is correct in OIIO, and Nuke, RV & ffmpeg > agree with it. > > -j > > On May 19, 2016, at 10:43 AM, Larry Gritz <[email protected]> wrote: > > Hi, Jonathan, thanks! > > If you could quickly read over the discussion in this PR: > https://github.com/OpenImageIO/oiio/pull/1412 > > (It's not overly long or technical, but it might make you scratch your head a > bit.) > > The question is: Do you know anything about what Nuke is up to in the cited > JPEG code? Do you believe Nuke is computing the aspect ratio for JPEG files > backwards (versus the JFIF spec), or do you think that my interpretation of > JFIF's fields are incorrect? > > If Nuke is wrong, does that mean that we'd better do it wrong, too, or be > forever doomed to have the aspect ratio being mangled when Nuke reads our > files or vice versa? Or is there another solution you can think of that > doesn't involve our having to introduce a bug? (I don't imagine that the > Foundry will deem it practical to suddenly change Nuke's interpretation at > this stage, even if it's technically wrong.) > > >> On May 19, 2016, at 10:02 AM, Jonathan Egstad <[email protected]> wrote: >> >> Hey Larry, >> I'm one of the original Nuke authors but not with the Foundry - if you need >> help with general plugin coding questions maybe I can help. >> >> Cheers, >> -j >> >> On May 18, 2016, at 10:18 AM, Larry Gritz <[email protected]> wrote: >> >> Anybody from the Foundry who works on Nuke reading this? > > -- > Larry Gritz > [email protected] > > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > _______________________________________________ > Oiio-dev mailing list > [email protected] > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org -- Larry Gritz [email protected] _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
