Sorry, the old Ctrl + Enter hotkey got me again...
I think an important thing here is to look at the command that was being
run:
oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio 2.0 -o
nonsquare.jpg
There is no non-uniform scaling being applied, and changing the pixel aspect
ratio of the image should not change its physical resolution at all. As
such, the result of this should be an image that, when viewed with proper
pixel aspect ratio correction, should appear to be twice as wide as the
original.
Now, about those metadata tags...
If you look at the EXIF tag definitions for XResolution and YResolution, the
language is a bit strange:
The number of pixels per <ResolutionUnit> in the <ImageWidth> direction.
[...]
If you reorient your thinking so the "resolution" of the image is actually
whatever <ResolutionUnit> is (defaults to inches), it starts to make some
sense. For a 512x512 square image at 72 dpi, the "resolution" is actually
7.111111 x 7.1111111.
Now, if the <XResolution> and <YResolution> values of that same image are
2400 and 1200, respectively, and we take the language of the EXIF tags
as-is, those 7.111111 inches of resolution are not going to be uniformly
mapped to screen pixels in both dimensions(remember, "pixels per
<ResolutionUnit>"). Instead, the result will be a "pixel image" twice as
wide as it is tall.
In practice, the resolution tags are treated as a ratio, and the image's
pixel resolution is read directly from the file.
Finally, even if you disagree with all of this (which I wouldn't really
fault you for), the fact is that Nuke, RV, and Adobe products currently all
agree on how they should be handled, so I think it might be best to try and
stay consistent.
-Nathan
-----Original Message-----
From: Larry Gritz
Sent: Wednesday, January 28, 2015 11:04 PM
To: OpenImageIO developers
Subject: Re: [Oiio-dev] aspect ratio from oiiotool
(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
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
