Yes, my understanding about JFIF vs JPEG matches your description. Like many
people, I often get lazy and write "JPEG" when what I mean is the container
file, not the compression method.
There are three separate questions to grapple with:
1. When xdensity > ydensity (i.e., XResolution > YResolution), and these are
"pixels per unit length", shouldn't that mean skinny pixels, not wide pixels,
by any rational interpretation of the JFIF standard?
2. Should a wide pixel be said to have an aspect ratio > 1.0, or < 1.0? That
informs which way the division of densities should go, to yield an aspect ratio
value to report (or the other way, translating a requested aspect into
densities).
3. Is Nuke doing it wrong? And if so, what should we do about it?
Two additional data points are worth mentioning:
* There is no doubt (including by Nuke) that a wide *frame* is said to have an
aspect ratio > 1.0. That's probably a strong hint about how we should describe
individual pixels as well.
* OpenEXR, in ImfStandardAttributes.h, has this to say about the relationship
between its xDensity and pixelAspectRatio attributes:
// xDensity -- horizontal output density, in pixels per inch.
// The image's vertical output density is xDensity * pixelAspectRatio.
So OpenEXR is also pretty clear that high density means small pixels, and that
pixel aspect = ydensity/xdensity, not the other way around.
What I think is going on is that the JFIF spec is completely clear about the
meaning, the libjpeg header comments either have a simple typo (as I have also
done several times in this conversation, typing X when I meant Y) or that the
person who wrote the comment misunderstood the JFIF spec, and the Nuke sample
plugin just blindly implemented what the libjpeg comment said rather than what
the JFIF spec says the fields are supposed to mean.
-- lg
On Jan 30, 2015, at 2:59 PM, Nathan Rusch <[email protected]> wrote:
> I certainly understand the argument you're making for resolution as it
> relates to pixel density from a logical perspective. I was going to put
> together a really long, detailed response explaining how I think the EXIF
> tags are being interpreted by other apps, even in the face of logic, but
> first I did some more reading and found something that I think more or less
> explains all of this:
>
> JPEG does not define any way of indicating pixel aspect ratio, but JFIF
> does... sort of.
>
> Remember (and this is something I had to remind myself), JPEG is only a
> codec. MySweetPicture.jpg is actually a JFIF file (or should be, anyway).
>
> From the JFIF spec (http://www.w3.org/Graphics/JPEG/jfif3.pdf):
>
> The JFIF APP0 marker provides information which is missing from the JPEG
> stream:
> version number, X and Y pixel density (dots per inch or dots per cm), pixel
> aspect ratio
> (derived from X and Y pixel density), thumbnail.
>
> "... (derived from X and Y pixel density)..."
>
>
> Unfortunately, it doesn't mention *how* it is derived from the density
> values, so I started poking around in the JPEG headers (jpeg-8d). And lo and
> behold, I found this:
>
> /* These three values are not used by the JPEG code, merely copied */
> /* into the JFIF APP0 marker. density_unit can be 0 for unknown, */
> /* 1 for dots/inch, or 2 for dots/cm. Note that the pixel aspect */
> /* ratio is defined by X_density/Y_density even when density_unit=0. */
> UINT8 density_unit; /* JFIF code for pixel size units */
> UINT16 X_density; /* Horizontal pixel density */
> UINT16 Y_density; /* Vertical pixel density */
>
> "Note that the pixel aspect ratio is defined by X_density/Y_density even when
> density_unit=0."
>
>
> I then looked over the sample jpegWriter plugin code that ships with Nuke,
> and sure enough, it sets XDensity and YDensity in the output file's
> jpeg_compress_struct:
>
> cinfo.Y_density = 1200;
> cinfo.X_density = (UINT16)(iop->format()->pixel_aspect() * cinfo.Y_density
> + .5)
>
> So, it appears Nuke is actually doing things "correctly," but the density
> values themselves are somewhat misleading.
>
>
> -Nathan
>
>
>
> -----Original Message----- From: Larry Gritz
> Sent: Friday, January 30, 2015 11:56 AM
> To: OpenImageIO developers
> Subject: Re: [Oiio-dev] aspect ratio from oiiotool
>
> On Jan 30, 2015, at 11:44 AM, Nathan Rusch <[email protected]> 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").
>>
>> There are no Density tags in the EXIF spec, but XResolution and YResolution
>> do exist.
>
> Sorry, I was using confusing terminology.
>
> To make it worse, the JPEG header has an xDensity and yDensity, and ALSO an
> Exif block that contains XResolution and YResolution, which are described as
> the same thing. I think we're all kind of punting on what happens when these
> seemingly coupled values contradict each other, and assuming that it's the
> Exif data that really counts.
>
> Now then...
>
>
>>
>>> 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.
>>
>> Based on the language in the EXIF spec, I'm not sure this is true. As I
>> mentioned in my previous message, the spec says this about the Resolution
>> tags:
>>
>> The number of pixels per <ResolutionUnit> in the <ImageWidth> direction.
>> [...]
>
>
> Right. If there are MORE pixels per ResolutionUnit, that means they are
> spaced closer together, i.e. smaller.
>
>
>
>> Using this language as a guide, an XResolution of 2400 and a YResolution of
>> 1200 makes sense for an image with a pixel aspect of 2.0, and I believe this
>> is how other applications (Adobe, RV, Nuke) handle "non-square pixels" in
>> JPEG files.
>
> If "XResolution" is number of pixel per ResolutionUnit (inch, cm, or
> undefined), that means that HIGHER resolution (aka density) means THINNER
> pixels, and LOWER resolution (density) means WIDER pixels.
>
> Once again, XResolution < YResolution means short wide pixels, XResolution >
> XResolution means tall skinny pixels.
>
> More pixels per inch horizontally than vertically means individual pixels are
> tall, not wide.
>
> So XResolution=2400, YResolution=1200 is a tall skinny pixel, which I think
> we would all describe as aspect ratio 0.5, whereas aspect ratio 2.0 would be
> a short wide pixel (perhaps with XResolution=1200, YResolution=2400), just
> like we describe a short wide FRAME as aspect ratio > 1.0.
>
> No?
>
> --
> 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
--
Larry Gritz
[email protected]
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
