https://www.thefoundry.co.uk/products/nuke/developers/100/ndkreference/examples/jpegReader.cpp
Has the reader code ... In the constructor there is bits dealing with the density values. Kevin Sent on the go... > On 19 May 2016, at 22:21, Jonathan Egstad <jegs...@earthlink.net> wrote: > > If it makes you feel any better, the Nuke notation is based on film > terminology where the anamorphic value refers to the projector lens stretch, > not the camera lens squeeze. i.e. 2.0 means x2 in display width. > > Typically anamorphic is not referred to as 0.5... > > -j > > On May 19, 2016, at 1:34 PM, Larry Gritz <l...@larrygritz.com> wrote: > > 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 <jegs...@earthlink.net> 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 <l...@larrygritz.com> 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 <jegs...@earthlink.net> 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 <l...@larrygritz.com> wrote: >>> >>> Anybody from the Foundry who works on Nuke reading this? >> >> -- >> Larry Gritz >> l...@larrygritz.com >> >> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org >> >> _______________________________________________ >> Oiio-dev mailing list >> Oiio-dev@lists.openimageio.org >> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > -- > Larry Gritz > l...@larrygritz.com > > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org > > _______________________________________________ > Oiio-dev mailing list > Oiio-dev@lists.openimageio.org > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org _______________________________________________ Oiio-dev mailing list Oiio-dev@lists.openimageio.org http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
