(WARNING: this whole explanation depends on your viewing with a fixed-width
font.)
I think maybe this is a disagreement between the different apps on what aspect
ratio means.
I very well could have screwed this up, so let me explain my thinking, and
people can tell me if it makes sense or if I botched it.
First of all, when we talk about the FRAME aspect ratio of a whole film image,
we say the aspect is 1.85, or 16/9, or 2.35, or whatever, all of which are
varying degrees of wider than they are tall. "Wider than tall" means a frame
aspect ratio of greater than 1.0, "taller than wide" means a frame aspect ratio
of less than 1.0. Right? So I'm gonna assume that the same is true of pixel
aspect ratio.
OK, here's my cartoon of a 2x2 image with square pixels. Let's make up some
densities, say the image is supposed to print 1 cm wide and 1 cm tall, so
XResolution = 2, YResolution = 2, ResolutionUnit = "cm".
+---+---+ ^
| * | * | |
+---+---+ 1cm
| * | * | |
+---+---+ v
<- 1cm ->
We agree that this is a 1.0 aspect ratio, I assume. (I do hope you're viewing
with a fixed width font)
So let's say we want to cut the density in half horizontally, giving us wide
pixels.
+-------+ ^
| * | |
+-------+ 1cm
| * | |
+-------+ v
<- 1cm ->
There are still 2 vertical samples per cm, but only 1 horizontal sample per
pixel. In other words, XResolution = 1, YResolution = 2.
What is the PixelAspectRatio?
Here's the shape of just one pixel:
+-------+
| |
+-------+
Remembering what we said about the aspect ratio of a whole frame, I would argue
that the aspect ratio of a pixel that is wider than it is tall also should be a
number greater than 1. For the above pixel, its PixelAspectRatio is 2.0, i.e.
YResolution/XResolution. Also known as ydensity/xdensity, because note that in
this terminology, "resolution" means "dots per length", like printer's
resolution, NOT the faux "resolution" we use to describe the number of pixels
in a whole image.
Nuke wrote an image that it says is 1047x858, with 2400 horizontal pixels per
inch (let's say; the units are undefined), so the image is 0.43625 inches
wide, and at a y density of 1200 pixels per inch, it should be 0.715 inches
tall:
<-0.436"->
^ +--------+
| | |
| | |
0.715"| |
| | |
| | |
| | |
| | |
v +--------+
Is that what you expect? It's a tall skinny image?
Or, do you expect a wide image? If you expect wide, then I'm going to go out
on a limb and claim that Nuke is totally botching the meaning of the density
fields, and thus the aspect ratio. Maybe rv is also getting it backwards,
either coincidentally having made the same mistake, or else purposely backwards
in order to match Nuke's broken output.
Somebody let me know if I'm totally borked in my thinking about this. Maybe I'm
the one who got it all wrong.
-- lg
PS. https://www.youtube.com/watch?v=Bt9zSfinwFA
On Jan 28, 2015, at 5:56 PM, ran sariel <[email protected]> wrote:
> oiiotool shows the aspect ratio attribute as written.
>
> channel list: R, G, B
> oiio:ColorSpace: "sRGB"
> jpeg:subsampling: "4:2:0"
> XResolution: 72
> YResolution: 144
> Exif:ColorSpace: 1
> IPTC:OriginatingProgram: "OpenImageIO 1.6.0dev :oiiotool in.exr --ch R,G,B
> --resize 50% --tocolorspace sRGB -attrib PixelAspectRatio 2.000000 -o
> nonsquare.jpg"
> PixelAspectRatio: 2
> ResolutionUnit: "none"
>
> a 'working version' rendered from nuke with aspect ratio of 2 shows in oiio as
>
> working.jpg : 1047 x 858, 3 channel, uint8 jpeg
> channel list: R, G, B
> oiio:ColorSpace: "sRGB"
> jpeg:subsampling: "4:4:4"
> XResolution: 2400
> YResolution: 1200
> PixelAspectRatio: 0.5
> ResolutionUnit: "none"
>
> the difference is that working.jpg displays correctly in RV, (the aspect
> ratio is read correctly from the file as 2.0)
> but working.jpg isn't.
>
>
> Ran
>
>
>
>
>
> On 01/28/2015 05:04 PM, Larry Gritz wrote:
>> I'm sorry, are you saying that rv doesn't tell you the aspect ratio? Or are
>> you saying that OIIO (e.g. "oiiotool -info -v nonsquare.jpg") doesn't tell
>> you the aspect ratio?
>>
>>
>>
>> On Jan 28, 2015, at 4:42 PM, ran sariel<[email protected]> wrote:
>>
>>> The build works fine so do the tests (for oiiotool at least).
>>>
>>> looking at the resulting image from the conversion (in RV or nuke.)
>>> I can see the exif/software info in RV
>>> openImageIO 1.6.0dev: oiiotool in.exr --ch R,G,B --resize 50% --attrib
>>> PixelAspectRatio 2.0 -o nonsquare.jpg
>>> But the PixelAspect is not seen by RV.
>>>
>>> oddly with or without passing the PixelAspectRation attrib I get the same
>>> metaData on the jpeg i get
>>> XResolution as 72/1
>>> YResolution as 144/1
>>>
>>> but no PixelAspectRatio written.
>>>
>>> hence my assumption that I'm working with the wrong branch...
>>>
>>>
>>> Ran
>>>
>>>
>>>
>>>
>>>
>>> On 01/28/2015 03:41 PM, Larry Gritz wrote:
>>>> I don't know what you mean. The patch I merged definitely had code changes
>>>> as well as tests. It should all be in the current master.
>>>>
>>>> -- lg
>>>>
>>>>
>>>> On Jan 27, 2015, at 9:43 AM, ran sariel<[email protected]> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I downloaded and rebuilt master. seems that the changes are not in the
>>>>> main /src folder but in testsuite.
>>>>> not sure if I'm building oiio correctly (the build instructions do not
>>>>> mention testsuite at all)
>>>>> Am I missing the correct branch? or should I apply the changes locally
>>>>> from the testsuite files to the /src folder
>>>>>
>>>>>
>>>>> Cheers
>>>>> Ran
>>>>>
>>>>>
>>>>> On 01/26/2015 11:20 AM, Larry Gritz wrote:
>>>>>> FYI, I have merged this fix into master.
>>>>>>
>>>>>> Since we're trying to push out a stable 1.5 release (today, ideally!), I
>>>>>> didn't want to mess with that branch. Let's test this change in master
>>>>>> for a while, and then if there is demand for a back-port, we can
>>>>>> consider making the change in 1.5 as well.
>>>>>>
>>>>>> -- lg
>>>>>>
>>>>>>
>>>>>> On Jan 23, 2015, at 5:53 PM, ran sariel<[email protected]>
>>>>>> wrote:
>>>>>>
>>>>>>> Thank you Larry, that's great news.
>>>>>>> ( I actually tried to set the --attrib for pixelAspectRatio, but it
>>>>>>> wasn't recognized by RV so I was assuming I got it wrong..)
>>>>>>>
>>>>>>> Cheers
>>>>>>> Ran
>>>>>>>
>>>>>>> On 01/23/2015 04:08 PM, Larry Gritz wrote:
>>>>>>>> OK, I did some digging, and it's a bit of a good news / bad news
>>>>>>>> situation.
>>>>>>>>
>>>>>>>> Bad news: JPEG doesn't directly store the pixel aspect ratio in its
>>>>>>>> metadata.
>>>>>>>>
>>>>>>>> Good news: JPEG does store "density" (dots per inch or cm in x and y),
>>>>>>>> and so the pixel aspect ratio is implied to be ydensity/xdensity.
>>>>>>>>
>>>>>>>> Bad news: our JPEG reader (and writer) didn't handle xdensity and
>>>>>>>> ydensity properly. (This is supposed to correspond to the standard
>>>>>>>> OIIO metadata called "XResolution" and "YResolution", which are
>>>>>>>> confusing names, but they are simply inherited from TIFF nomenclature.)
>>>>>>>>
>>>>>>>> Good news: I have a pull request
>>>>>>>> (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and
>>>>>>>> also tightens up the way we handle the mutual interactions of
>>>>>>>> XResolution, YResolution, and PixelAspectRatio.
>>>>>>>>
>>>>>>>> Once this PR is approved and merged, you'll be able to set the implied
>>>>>>>> pixel aspect ratio of a JPEG file like this:
>>>>>>>>
>>>>>>>> oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o
>>>>>>>> nonsquare.jpg
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 22, 2015, at 9:46 AM, ran sariel<[email protected]>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> just change the metadata
>>>>>>>>>
>>>>>>>>> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>>>>>>>>>> aspect ratio
>>>>>>>>> --
>>>>>>>>> Ran Sariel
>>>>>>>>> CTO / Pipeline supervisor
>>>>>>>>> The Embassy VFX Inc.
>>>>>>>>> 177 West 7th Ave, 4th Floor
>>>>>>>>> Vancouver, BC
>>>>>>>>> Phone: (604) 696-6862 ext. 244
>>>>>>>>>
>>>>>>>>> [email protected]
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Larry Gritz
>>>>>>>> [email protected]
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> [email protected]
>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>> --
>>>>>>> Ran Sariel
>>>>>>> CTO / Pipeline supervisor
>>>>>>> The Embassy VFX Inc.
>>>>>>> 177 West 7th Ave, 4th Floor
>>>>>>> Vancouver, BC
>>>>>>> Phone: (604) 696-6862 ext. 244
>>>>>>>
>>>>>>> [email protected]
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> 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
>>>>> --
>>>>> Ran Sariel
>>>>> CTO / Pipeline supervisor
>>>>> The Embassy VFX Inc.
>>>>> 177 West 7th Ave, 4th Floor
>>>>> Vancouver, BC
>>>>> Phone: (604) 696-6862 ext. 244
>>>>>
>>>>> [email protected]
>>>>>
>>>>> _______________________________________________
>>>>> 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
>>> --
>>> Ran Sariel
>>> CTO / Pipeline supervisor
>>> The Embassy VFX Inc.
>>> 177 West 7th Ave, 4th Floor
>>> Vancouver, BC
>>> Phone: (604) 696-6862 ext. 244
>>>
>>> [email protected]
>>>
>>> _______________________________________________
>>> 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
>
> --
> Ran Sariel
> CTO / Pipeline supervisor
> The Embassy VFX Inc.
> 177 West 7th Ave, 4th Floor
> Vancouver, BC
> Phone: (604) 696-6862 ext. 244
>
> [email protected]
>
> _______________________________________________
> 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
