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?
Yes, I completely agree with you here. However, to play devil's advocate,
while the JFIF standard defines the pixel aspect ratio as being derived from
the XDensity and YDensity, it stops short of mentioning exactly how it
should be derived, so I can understand how it could potentially be
interpreted the "wrong" way if someone wasn't thinking everything through.
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).
As far as I'm concerned, a "wide pixel" should have an aspect ratio > 1.0,
resulting in a lower horizontal density, which I believe is in line with
your argument.
3. Is Nuke doing it wrong? And if so, what should we do about it?
If Nuke is doing it wrong, they certainly aren't the only ones. Photoshop
(CS4 in my case) and RV both display anamorphic .jpg files written out of
Nuke as Nuke meant them to be displayed. Granted, RV is using libjpeg as
well, but their reader plugin still has to translate the JPEG density
attributes into a pixel aspect ratio for display in RV, which means either
they took the libjpeg source comment at face value as well, or they know
something we don't. I can't explain Photoshop's behavior at all.
It seems absurd, but kind of looks like its going to come down to whether
you would rather OIIO be technically correct (as we understand it), but
annoy people and prompt them to submit erroneous bug reports by creating
images that look wrong in all the applications they are viewed in, or have
it be "wrong" for the sole purpose of keeping people happy. Tough call
indeed...
Is it worth getting in touch with the maintainers of libjpeg to see if they
would stand by the comment in their source as it relates to the JFIF spec?
Or maybe just asking The Foundry and Tweak about performing an about-face?
-Nathan
-----Original Message-----
From: Larry Gritz
Sent: Friday, January 30, 2015 3:28 PM
To: OpenImageIO developers
Subject: Re: [Oiio-dev] aspect ratio from oiiotool
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
_______________________________________________
Oiio-dev mailing list
[email protected]
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
