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]> 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]> 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]> 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]> 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]>  
>>> >> 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
>>> 
>>> --
>>> 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
> 
> -- 
> 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

Reply via email to