On May 19, 2016, at 2:41 PM, Kevin Wheatley <[email protected]> wrote:
>
> 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
Right! It says:
aspect = (float)cinfo.X_density / (float)cinfo.Y_density
If xdensity = 100 pixels per inch and ydensity = 200 pixels per inch, a 512x512
image needs to look wide, not narrow (which is how Nuke displays it)!
>
> Sent on the go...
>
>> On 19 May 2016, at 22:21, 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
> _______________________________________________
> 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
