Awesome - works!

On 02/18/2015 03:31 PM, Larry Gritz wrote:
Fix: https://github.com/OpenImageIO/oiio/pull/1066


On Feb 18, 2015, at 2:56 PM, Larry Gritz <[email protected] <mailto:[email protected]>> wrote:

Ah, I think. Hang on, I'll check this. There may be a conflict between the jpeg_compress_struct and the Exif data.


On Feb 18, 2015, at 2:44 PM, ran sariel <[email protected] <mailto:[email protected]>> wrote:

Hi Larry

sent a mail to the tweak support, here's the reply

Hi Ran,

We are using the relationship between the X_density and the Y_density of the jpeg_compress_struct. Specifically:

pixel aspect = x density / y density

Is that sufficient?

Thanks,
Jon


hope that makes sense




On 02/18/2015 02:22 PM, Larry Gritz wrote:
Then I do not understand how RV expects to have this information communicated. As you can see, the XResolution and YResolution (in the Exif data) do indicate a non-square aspect ratio.

Do you know what RV is expecting to clue it in on the aspect?



On Feb 18, 2015, at 2:16 PM, ran sariel <[email protected] <mailto:[email protected]>> wrote:

Same here Larry.
oiiotool is consistent with itself. (always was)
the outside world (i.e in this case RV) does not see that as something to get pixelAspect Ratio from hence displays it as square image.

Cheers
Ran

On 02/18/2015 02:10 PM, Larry Gritz wrote:
In what way, exactly, is it not doing anything? For me:

*$ oiiotool green.exr -attrib "PixelAspectRatio" 0.5 -o nonsquare.jpg*
*$ oiiotool -v -info nonsquare.jpg*
nonsquare.jpg : 1024 x 1024, 3 channel, uint8 jpeg
    channel list: R, G, B
    oiio:ColorSpace: "sRGB"
    jpeg:subsampling: "4:2:0"
    Orientation: 1 (normal)
Software: "OpenImageIO 1.6.1dev : oiiotool green.exr -attrib PixelAspectRatio 0.5 -o nonsquare.jpg"
    DateTime: "2014:11:30  8:46:29"
    XResolution: 72
    YResolution: 36
IPTC:OriginatingProgram: "OpenImageIO 1.6.1dev : oiiotool green.exr -attrib PixelAspectRatio 0.5 -o nonsquare.jpg"
    PixelAspectRatio: 0.5
    ResolutionUnit: "none"


What does it do for you?


On Feb 18, 2015, at 2:01 PM, Ran Sariel <[email protected] <mailto:[email protected]>> wrote:

current master.
oiiotool  in.exr -attrib "PixelAspectRatio" 0.5 -o nonsquare.jpg


On Wed, Feb 18, 2015 at 1:50 PM, Larry Gritz <[email protected] <mailto:[email protected]>> wrote:

    This is with the current master, or with the head of RB-1.5?
    JPEG file? Can you tell me exactly what command line you tried?



    On Feb 18, 2015, at 1:22 PM, ran sariel
    <[email protected]
    <mailto:[email protected]>> wrote:

    > Hey Larry
    >
    > no still not working,.
    > I'm passing in 0.5 as the PixelAspectRatio and still
    getting a square image in RV, seems that the -attrib
    "PixelAspectRatio" is not doing anything.
    >
    > Ran
    >
    >
    > 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]
    <mailto:[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]
    <mailto:[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] <mailto:[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] <mailto:[email protected]>
    >>>>>>
    >>>>>>
    >>>>>>
    >>>>>> _______________________________________________
    >>>>>> Oiio-dev mailing list
    >>>>>> [email protected]
    <mailto:[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
    <tel:%28604%29%20696-6862%20ext.%20244>
    >>>>>
    >>>>> [email protected] <mailto:[email protected]>
    >>>>>
    >>>>> _______________________________________________
    >>>>> Oiio-dev mailing list
    >>>>> [email protected]
    <mailto:[email protected]>
    >>>>>
    http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
    >>>> --
    >>>> Larry Gritz
    >>>> [email protected] <mailto:[email protected]>
    >>>>
    >>>>
    >>>>
    >>>> _______________________________________________
    >>>> Oiio-dev mailing list
    >>>> [email protected]
    <mailto:[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
    <tel:%28604%29%20696-6862%20ext.%20244>
    >>>
    >>> [email protected] <mailto:[email protected]>
    >>>
    >>> _______________________________________________
    >>> Oiio-dev mailing list
    >>> [email protected]
    <mailto:[email protected]>
    >>>
    http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
    >> --
    >> Larry Gritz
    >> [email protected] <mailto:[email protected]>
    >>
    >>
    >>
    >> _______________________________________________
    >> Oiio-dev mailing list
    >> [email protected]
    <mailto:[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
    <tel:%28604%29%20696-6862%20ext.%20244>
    >
    > [email protected] <mailto:[email protected]>
    >
    > _______________________________________________
    > Oiio-dev mailing list
    > [email protected]
    <mailto:[email protected]>
    >
    http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

    --
    Larry Gritz
    [email protected] <mailto:[email protected]>



    _______________________________________________
    Oiio-dev mailing list
    [email protected]
    <mailto:[email protected]>
    http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org


_______________________________________________
Oiio-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected] <mailto:[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] <mailto:[email protected]>
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected] <mailto:[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] <mailto:[email protected]>
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected] <mailto:[email protected]>



_______________________________________________
Oiio-dev mailing list
[email protected] <mailto:[email protected]>
http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
[email protected] <mailto:[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

Reply via email to