Re: [Oiio-dev] Any Nuke authors out there?

[Mark Visser]

Do you think it might be useful to get in contact with the ISO committee?
For all practical purposes, the standard is "wrong" and should be updated.

I think this is the committee in question:
http://www.iso.org/iso/home/standards_development/list_of_iso_technical_committees/iso_technical_committee.htm?commid=45020

cheers,
-Mark

On Wed, Jun 1, 2016 at 7:02 PM, Larry Gritz  wrote:

> My guess is Photoshop was the first tool to consider this metadata and got
> it wrong, and everyone else is copying Photoshop.
>
>
> Yeah, that seems very likely to me.
>
> And here we are, about to take the only identified instance of software
> that got it right, and break it in order to be compatible with all the ones
> who got it wrong. :-(   (I see no practical alternative to this plan.)
>
>
> On Jun 1, 2016, at 1:34 PM, Jonathan Gibbs  wrote:
>
> This is just a totally fascinating study of modern software. It's
> fascinating that you have a spec as widely adopted as JFIF/JPEG, and
> clearly the original engineers did a good job specifying some important
> meta-data. I'm sure they had all sorts of use cases where this was
> important.
>
> And yet (a) very little software handles it at all, and (b) those who do
> get it wrong.
>
> When does Software Archeologist become a well-paid job? That would be an
> interesting thing to be called out of retirement to do some day. :)
>
> My guess is Photoshop was the first tool to consider this metadata and got
> it wrong, and everyone else is copying Photoshop.
>
> FWIW, Houdini's "mplay" image/flipbook viewer seems to ignore it too.
>
> --jono
>
>
> On Fri, May 20, 2016 at 1:36 AM Kevin Wheatley 
> wrote:
>
>> now I'm at work the best documentation I have is from ITU T.871 which
>> is ISO/IEC 10918-5:
>>
>> Units for the H (horizontal) and V (vertical) densities:
>> = X'00': units unspecified; H and V densities, expressed in dots per
>> arbitrary unit, specify only the pixel aspect ratio (width:height
>> pixel aspect ratio = Vdensity:Hdensity).
>>
>> which is more explicit than the JFIF 1.02 de facto standard, which was
>> what I read last night. JFIF 1.02 I thought could be read in an
>> ambiguous manner.
>>
>> This is much better, but reinforces something I mentioned to some
>> people yesterday; specifications should come with some form of
>> examples/reference implementation, especially when tying together
>> multiple standards or when there are variations supported due to
>> combining multiple proposals.
>>
>> Kevin
>> ___
>> 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

Re: [Oiio-dev] Any Nuke authors out there?

[Larry Gritz]

> My guess is Photoshop was the first tool to consider this metadata and got it 
> wrong, and everyone else is copying Photoshop.

Yeah, that seems very likely to me.

And here we are, about to take the only identified instance of software that 
got it right, and break it in order to be compatible with all the ones who got 
it wrong. :-(   (I see no practical alternative to this plan.)


> On Jun 1, 2016, at 1:34 PM, Jonathan Gibbs  wrote:
> 
> This is just a totally fascinating study of modern software. It's fascinating 
> that you have a spec as widely adopted as JFIF/JPEG, and clearly the original 
> engineers did a good job specifying some important meta-data. I'm sure they 
> had all sorts of use cases where this was important. 
> 
> And yet (a) very little software handles it at all, and (b) those who do get 
> it wrong.
> 
> When does Software Archeologist become a well-paid job? That would be an 
> interesting thing to be called out of retirement to do some day. :)
> 
> My guess is Photoshop was the first tool to consider this metadata and got it 
> wrong, and everyone else is copying Photoshop.
> 
> FWIW, Houdini's "mplay" image/flipbook viewer seems to ignore it too.
> 
> --jono
> 
> 
> On Fri, May 20, 2016 at 1:36 AM Kevin Wheatley  > wrote:
> now I'm at work the best documentation I have is from ITU T.871 which
> is ISO/IEC 10918-5:
> 
> Units for the H (horizontal) and V (vertical) densities:
> = X'00': units unspecified; H and V densities, expressed in dots per
> arbitrary unit, specify only the pixel aspect ratio (width:height
> pixel aspect ratio = Vdensity:Hdensity).
> 
> which is more explicit than the JFIF 1.02 de facto standard, which was
> what I read last night. JFIF 1.02 I thought could be read in an
> ambiguous manner.
> 
> This is much better, but reinforces something I mentioned to some
> people yesterday; specifications should come with some form of
> examples/reference implementation, especially when tying together
> multiple standards or when there are variations supported due to
> combining multiple proposals.
> 
> Kevin
> ___
> 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

Re: [Oiio-dev] Any Nuke authors out there?

[Larry Gritz]

On Jun 1, 2016, at 1:34 PM, Jonathan Gibbs  wrote:
> 
> When does Software Archeologist become a well-paid job? That would be an 
> interesting thing to be called out of retirement to do some day. :)


I think those retired COBOL programmers charged a fortune to clean up the Y2K 
mess. I'm sure there will be some VFX equivalent for you in 20 years.

--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Any Nuke authors out there?

[Larry Gritz]

That code listing doesn't appear to examine the cinfo.density_unit field at all.

Also, nothing in the JFIF spec indicates that if density_unit is 0, the density 
fields suddenly switch to mean the inverse. As far as I can tell, it just means 
that the units are unknown/unspecified, but it's still a density (1/length). 



> On May 19, 2016, at 2:57 PM, Kevin Wheatley  
> wrote:
> 
> 
> 
> Sent on the go...
> 
>> On 19 May 2016, at 22:48, Jonathan Egstad  wrote:
>> 
>> 
>> Nuke's JPEG reader/writer is interpreting the xdensity and ydensity fields 
>> as sizes, not densities.
> 
> But does it not depend on the other header field if the units header has a 
> non zero value to be interpreted as a density, else it is an aspect ratio...
> 
> Which I could see as  2:1 meaning make a wide image... But when set as a 
> density it means the opposite no?
> 
> Kevin
> 
> 

--
Larry Gritz
l...@larrygritz.com


___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Any Nuke authors out there?

[Kevin Wheatley]

Sent on the go...

> On 19 May 2016, at 22:48, Jonathan Egstad  wrote:
> 
> 
> Nuke's JPEG reader/writer is interpreting the xdensity and ydensity fields as 
> sizes, not densities.

But does it not depend on the other header field if the units header has a non 
zero value to be interpreted as a density, else it is an aspect ratio...

Which I could see as  2:1 meaning make a wide image... But when set as a 
density it means the opposite no?

Kevin

___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

Re: [Oiio-dev] Any Nuke authors out there?

[Larry Gritz]

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  wrote:
> 
> The industry did not evolve in a scientifically rigorous way.  ;)
> 
> 
> On May 19, 2016, at 2:43 PM, Larry Gritz  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  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  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  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  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  
 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.
 
 

Re: [Oiio-dev] Any Nuke authors out there?

[Jonathan Egstad]

The industry did not evolve in a scientifically rigorous way.  ;)


On May 19, 2016, at 2:43 PM, Larry Gritz  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  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  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  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  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  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  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

Re: [Oiio-dev] Any Nuke authors out there?

[Larry Gritz]

On May 19, 2016, at 2:41 PM, Kevin Wheatley  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  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  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  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  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  
 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  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
>> 

Re: [Oiio-dev] Any Nuke authors out there?

[Kevin Wheatley]

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  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  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  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  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  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  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

Re: [Oiio-dev] Any Nuke authors out there?

[Jonathan Egstad]

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  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  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  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  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  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

Re: [Oiio-dev] Any Nuke authors out there?

[Larry Gritz]

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  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  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  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  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

Re: [Oiio-dev] Any Nuke authors out there?

[Jonathan Egstad]

(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  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  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  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

Re: [Oiio-dev] Any Nuke authors out there?

[Jonathan Egstad]

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  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


Sent from my iPhone
___
Oiio-dev mailing list
Oiio-dev@lists.openimageio.org
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

[Oiio-dev] Any Nuke authors out there?

[Larry Gritz]

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