sounds good,
will rebuild and let you know if I find any issues..
On 02/18/2015 12:08 PM, Larry Gritz wrote:
Yes, PixelAspectRatio has had these fixes (improved for JPEG, TIFF, and
OpenEXR) in the current master for a couple weeks now, with no complaints, so I
just backported it to 1.5. It should be in the current RB-1.5 top of tree, but
I have not yet tagged a release for it yet.
Note that we try to do it *correctly*, but have identified a way in which, just for JPEG
files, Nuke, PhotoShop, and RV do something weird and apparently contrary to the JFIF
spec. The net result is that if you are using oiiotool to set the PixelAspectRatio for a
JPEG file that will be consumed by one of those programs, you may have to specify the
inverse of the aspect ratio (e.g., 0.5 when you really want 2 for a "wide"
pixel). This is only an issue for JPEG files with non-square aspect.
-- lg
On Feb 18, 2015, at 9:32 AM, ran sariel<[email protected]> wrote:
Hi Larry
Has there been any changes to support the pixelAspectRatio?.
Cheers
Ran
On 02/03/2015 10:30 PM, Larry Gritz wrote:
I'm liking this plan. Let's proceed for now by doing the right thing, and a few
people who notice a problem can just invert how they request aspect ratio from
oiiotool.
If this is a continual problem (more and more people confused by this behavior, reporting
it as a bug), then we can consider doing the "wrong" thing, just for JPEG, in
order to produce files that use the same incorrect convention as Nuke and RV.
I'm crossing my fingers that the combination of non-square pixel aspect and
JPEG files is rare -- after all, nobody had noticed the issue at all until now.
-- lg
On Jan 30, 2015, at 5:17 PM, ran sariel<[email protected]> wrote:
since I'm the one bringing all this headache ..
I'm totally happy with defining PixelAspectRatio as 0.5 when converting with
oiiotool. expecting it to show in the RV/Photoshot as aspectRatio 2.
On 01/30/2015 04:58 PM, Larry Gritz wrote:
On Jan 30, 2015, at 4:38 PM, Nathan Rusch<[email protected]> wrote:
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...
Head exploding...
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?
I'm happy to contact all three. But if they change, there will be a versionitis
problem between old and new versions of those packages. And in any case,
PhotoShop is still backwards as well, and my intuition is that my chances of
getting them to change, or to care at all, is much less than with Nuke and rv,
where at least I know people who would humor me by listening to me make a case
for it.
Sigh. I'll do some experiments to see if there's any way around this. At the very
least, I want to restrict the wrongness to be completely contained in the JPEG
read/write, and not infect the rest of OIIO (including the app side), where
aspect> 1 should certainly mean wide pixels.
Another consideration: In 6 years, we have not had a single comment about our JPEG I/O
not supporting aspect ratio or the resolution fields until this week, so perhaps the
number of people who will be annoyed by our doing it "right" may be extremely
limited, and a better solution is to make sure those few people know the weird set of
hoops to jump through to make the images right in Nuke and rv (e.g., if you want aspect
2.0, you should ask oiiotool for 0.5).
-- lg
--
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
