I think in this case the important thing to look at is the original command
that was run:
-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
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
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
