Unfortunately the prudent answer is often to go with the flow - especially with respect to Photoshop. I’m not a regular PS/Adobe user but I suspect jpegs are one of the heaviest used formats for Adobe users, so if PS is interpreting/writing those vars a certain way I’d follow their lead.
If anyone with access can test AE, Lightroom and perhaps iPhoto & Aperture to see what they do I think that’s enough weight to make the decision for you. Besides, I don’t think there’s anyone in particular with the moral authority to say “do it this way” - it’s usually a group consensus. (although I’m game for making a unilateral decree - what’s the worst that could happen? ;-) ) -j On May 19, 2016, at 2:53 PM, Larry Gritz <[email protected]> wrote: > 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 _______________________________________________ Oiio-dev mailing list [email protected] http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
