I'm assuming that the frame should appear much wider than it is tall, the individual pixels should be wider than tall, and that the grey checks in the image should look square if the image is drawn properly?
Both OIIO and OSX's Preview.app report XResolution=2400 and YResolution=1200. If the resolution fields are defined as "pixels per inch (or cm or unknown unit)", then how is this correct? Higher X resolution than Y means that the pixels are crammed more tightly together in the x direction than in the y direction, and thus the pixels should appear tall and skinny, not short and wide. If I don't understand this properly, please ELI5. On Jan 30, 2015, at 12:34 PM, ran sariel <[email protected]> wrote: > please find attached > > > > On 01/30/2015 11:17 AM, Larry Gritz wrote: >> If the pixels are wider than they are tall, then the JPEG metadata should >> have xDensity (what OIIO reports as "XResolution", using the TIFF >> terminology) SMALLER than the xDensity (OIIOs "YResolution"). >> >> The "working version" rendered from Nuke, as you reported, said that the >> XResolution = 2400 and YResolution = 1200. That is supposed to mean pixels >> that are taller than they are wide, because the density of pixels is higher >> horizontally than vertically. >> >> Can you send me (via private email is fine) one of those images that comes >> from Nuke so I can inspect exactly what's going on? >> >> Just to clarify again, there is no such thing as "PixelAspectRatio" metadata >> in a JPEG file (whereas there is in OpenEXR, for example). It just doesn't >> exist as such, in JPEG files. The pixel aspect is implied by the x and y >> density values. OIIO tries to shield you from this, computing the ratio and >> reporting it as PixelAspectRatio, and also if you give it a >> PixelAspectRatio, it will make sure to output densities that give the right >> ratio. >> >> -- lg >> >> >> On Jan 30, 2015, at 10:34 AM, ran sariel<[email protected]> wrote: >> >>> Hi Larry >>> >>> yes with PixelAspectRatio of 2 a square image will look twice as wide, >>> The individual pixesl are wider than they are tall. >>> >>> >>> On 01/29/2015 11:16 PM, Larry Gritz wrote: >>>> Sorry for the delay, I was tied up ALL day today. >>>> >>>> I'm still not clear on the basics of the situation. >>>> >>>> Is the image supposed to look wider than it is tall? >>>> >>>> Are the individual pixels in the image supposed to be wider than they are >>>> tall? >>>> >>>> >>>> >>>> On Jan 29, 2015, at 10:56 AM, ran sariel<[email protected]> >>>> wrote: >>>> >>>>> actually in this case, the resize is not changing the result, >>>>> running the conversion without the resize on the input image (exr with >>>>> pixelAspectRatio 2 - according to both RV and oiiotool.) >>>>> I get a jpeg image that is not recognized by RV as having >>>>> PixelAspectRatio of 2. >>>>> oiiotool recognizes that the image has a PixelAspectRatio attribute with >>>>> a value of 2. >>>>> I guess other packages are expecting something different than that >>>>> attribute, RV shows the density as 2400x1200 for the file written from >>>>> nuke. and as 1 for the file converted by oiiotool. >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> >>>>> On 01/29/2015 09:58 AM, Nathan Rusch wrote: >>>>>> 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 >>>>> -- >>>>> 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] > > <alexa_anamorphic.jpg>_______________________________________________ > 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
