Yeah, yeah, I know. :-) I just want somebody to say, "you're late to the game, but the rest of us decided a long time ago to stick together and do the opposite of what the JFIF standard says, trust us you won't break anything."
> On May 19, 2016, at 2:48 PM, Jonathan Egstad <[email protected]> wrote: > > The industry did not evolve in a scientifically rigorous way. ;) > > > On May 19, 2016, at 2:43 PM, Larry Gritz <[email protected]> wrote: > > Yeah, I'm fine with whatever they want to call it internally. > > OpenEXR/ImfStandardAttributes.h agrees with me: > > // > // xDensity -- horizontal output density, in pixels per inch. > // The image's vertical output density is xDensity * pixelAspectRatio. > // > > When I make an exr file with ydensity=xdensity*pixelaspectratio, and a par=2, > I get a wide image in Nuke. > > When I make a JPEG with ydensity=xdensity*pixelaspectratio and par=2, I get a > skinny image in Nuke. > > Nuke's JPEG reader/writer is interpreting the xdensity and ydensity fields as > sizes, not densities. > > But then again, so are PhotoShop, ffmpeg, and rv. OIIO is the only package > that seems to take the JFIF spec on face value. I don't see how we have much > choice other than to also be wrong, we certainly can't make files that will > come out wrong in many VFX apps. > > >> On May 19, 2016, at 2:21 PM, Jonathan Egstad <[email protected]> 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 <[email protected]> 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 <[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 >> >> _______________________________________________ >> 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 > > _______________________________________________ > 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
