[Oiio-dev] aspect ratio from oiiotool

[ran sariel]

Hi

Is there a way to write aspect ratio from oiiotool, specifically into
jpeg images ?


--
Ran Sariel
CTO / Pipeline supervisor
The Embassy VFX Inc.
177 West 7th Ave, 4th Floor
Vancouver, BC
Phone: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

Do you want to resize the image (changing its aspect ratio overall)? Or just change the metadata that indicates the aspect ratio of the individual pixels?


On Jan 21, 2015, at 2:24 PM, ran sariel <***@theembassyvfx.com> wrote:

> Hi
>
> Is there a way to write aspect ratio from oiiotool, specifically into jpeg images ?
>

--
Larry Gritz
***@larrygritz.com

[ran sariel]

just change the metadata

On 01/22/2015 12:30 AM, Larry Gritz wrote:
> aspect ratio

--
Ran Sariel
CTO / Pipeline supervisor
The Embassy VFX Inc.
177 West 7th Ave, 4th Floor
Vancouver, BC
Phone: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

OK, I did some digging, and it's a bit of a good news / bad news situation.

Bad news: JPEG doesn't directly store the pixel aspect ratio in its metadata.

Good news: JPEG does store "density" (dots per inch or cm in x and y), and so the pixel aspect ratio is implied to be ydensity/xdensity.

Bad news: our JPEG reader (and writer) didn't handle xdensity and ydensity properly. (This is supposed to correspond to the standard OIIO metadata called "XResolution" and "YResolution", which are confusing names, but they are simply inherited from TIFF nomenclature.)

Good news: I have a pull request (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and also tightens up the way we handle the mutual interactions of XResolution, YResolution, and PixelAspectRatio.

Once this PR is approved and merged, you'll be able to set the implied pixel aspect ratio of a JPEG file like this:

oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o nonsquare.jpg


On Jan 22, 2015, at 9:46 AM, ran sariel <***@theembassyvfx.com> wrote:

> just change the metadata
>
> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>> aspect ratio
>
> --
> Ran Sariel
> CTO / Pipeline supervisor
> The Embassy VFX Inc.
> 177 West 7th Ave, 4th Floor
> Vancouver, BC
> Phone: [phone] ext. 244
>
> ***@theembassyvfx.com
>

--
Larry Gritz
***@larrygritz.com

[ran sariel]

Thank you Larry, that's great news.
( I actually tried to set the --attrib for pixelAspectRatio, but it
wasn't recognized by RV so I was assuming I got it wrong..)

Cheers
Ran

On 01/23/2015 04:08 PM, Larry Gritz wrote:
> OK, I did some digging, and it's a bit of a good news / bad news situation.
>
> Bad news: JPEG doesn't directly store the pixel aspect ratio in its metadata.
>
> Good news: JPEG does store "density" (dots per inch or cm in x and y), and so the pixel aspect ratio is implied to be ydensity/xdensity.
>
> Bad news: our JPEG reader (and writer) didn't handle xdensity and ydensity properly. (This is supposed to correspond to the standard OIIO metadata called "XResolution" and "YResolution", which are confusing names, but they are simply inherited from TIFF nomenclature.)
>
> Good news: I have a pull request (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and also tightens up the way we handle the mutual interactions of XResolution, YResolution, and PixelAspectRatio.
>
> Once this PR is approved and merged, you'll be able to set the implied pixel aspect ratio of a JPEG file like this:
>
> oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o nonsquare.jpg
>
>
> On Jan 22, 2015, at 9:46 AM, ran sariel<***@theembassyvfx.com> wrote:
>
>> just change the metadata
>>
>> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>>> aspect ratio
>> --
>> Ran Sariel
>> CTO / Pipeline supervisor
>> The Embassy VFX Inc.
>> 177 West 7th Ave, 4th Floor
>> Vancouver, BC
>> Phone: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>>
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

FYI, I have merged this fix into master.

Since we're trying to push out a stable 1.5 release (today, ideally!), I didn't want to mess with that branch. Let's test this change in master for a while, and then if there is demand for a back-port, we can consider making the change in 1.5 as well.

-- lg


On Jan 23, 2015, at 5:53 PM, ran sariel <***@theembassyvfx.com> wrote:

> Thank you Larry, that's great news.
> ( I actually tried to set the --attrib for pixelAspectRatio, but it wasn't recognized by RV so I was assuming I got it wrong..)
>
> Cheers
> Ran
>
> On 01/23/2015 04:08 PM, Larry Gritz wrote:
>> OK, I did some digging, and it's a bit of a good news / bad news situation.
>>
>> Bad news: JPEG doesn't directly store the pixel aspect ratio in its metadata.
>>
>> Good news: JPEG does store "density" (dots per inch or cm in x and y), and so the pixel aspect ratio is implied to be ydensity/xdensity.
>>
>> Bad news: our JPEG reader (and writer) didn't handle xdensity and ydensity properly. (This is supposed to correspond to the standard OIIO metadata called "XResolution" and "YResolution", which are confusing names, but they are simply inherited from TIFF nomenclature.)
>>
>> Good news: I have a pull request (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and also tightens up the way we handle the mutual interactions of XResolution, YResolution, and PixelAspectRatio.
>>
>> Once this PR is approved and merged, you'll be able to set the implied pixel aspect ratio of a JPEG file like this:
>>
>> oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o nonsquare.jpg
>>
>>
>> On Jan 22, 2015, at 9:46 AM, ran sariel<***@theembassyvfx.com> wrote:
>>
>>> just change the metadata
>>>
>>> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>>>> aspect ratio
>>> --
>>> Ran Sariel
>>> CTO / Pipeline supervisor
>>> The Embassy VFX Inc.
>>> 177 West 7th Ave, 4th Floor
>>> Vancouver, BC
>>> Phone: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>>
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[ran sariel]

Hi

I downloaded and rebuilt master. seems that the changes are not in the
main /src folder but in testsuite.
not sure if I'm building oiio correctly (the build instructions do not
mention testsuite at all)
Am I missing the correct branch? or should I apply the changes locally
from the testsuite files to the /src folder


Cheers
Ran


On 01/26/2015 11:20 AM, Larry Gritz wrote:
> FYI, I have merged this fix into master.
>
> Since we're trying to push out a stable 1.5 release (today, ideally!), I didn't want to mess with that branch. Let's test this change in master for a while, and then if there is demand for a back-port, we can consider making the change in 1.5 as well.
>
> -- lg
>
>
> On Jan 23, 2015, at 5:53 PM, ran sariel<***@theembassyvfx.com> wrote:
>
>> Thank you Larry, that's great news.
>> ( I actually tried to set the --attrib for pixelAspectRatio, but it wasn't recognized by RV so I was assuming I got it wrong..)
>>
>> Cheers
>> Ran
>>
>> On 01/23/2015 04:08 PM, Larry Gritz wrote:
>>> OK, I did some digging, and it's a bit of a good news / bad news situation.
>>>
>>> Bad news: JPEG doesn't directly store the pixel aspect ratio in its metadata.
>>>
>>> Good news: JPEG does store "density" (dots per inch or cm in x and y), and so the pixel aspect ratio is implied to be ydensity/xdensity.
>>>
>>> Bad news: our JPEG reader (and writer) didn't handle xdensity and ydensity properly. (This is supposed to correspond to the standard OIIO metadata called "XResolution" and "YResolution", which are confusing names, but they are simply inherited from TIFF nomenclature.)
>>>
>>> Good news: I have a pull request (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and also tightens up the way we handle the mutual interactions of XResolution, YResolution, and PixelAspectRatio.
>>>
>>> Once this PR is approved and merged, you'll be able to set the implied pixel aspect ratio of a JPEG file like this:
>>>
>>> oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o nonsquare.jpg
>>>
>>>
>>> On Jan 22, 2015, at 9:46 AM, ran sariel<***@theembassyvfx.com> wrote:
>>>
>>>> just change the metadata
>>>>
>>>> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>>>>> aspect ratio
>>>> --
>>>> Ran Sariel
>>>> CTO / Pipeline supervisor
>>>> The Embassy VFX Inc.
>>>> 177 West 7th Ave, 4th Floor
>>>> Vancouver, BC
>>>> Phone: [phone] ext. 244
>>>>
>>>> ***@theembassyvfx.com
>>>>
>>> --
>>> Larry Gritz
>>> ***@larrygritz.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> 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: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

I don't know what you mean. The patch I merged definitely had code changes as well as tests. It should all be in the current master.

-- lg


On Jan 27, 2015, at 9:43 AM, ran sariel <***@theembassyvfx.com> wrote:

> Hi
>
> I downloaded and rebuilt master. seems that the changes are not in the main /src folder but in testsuite.
> not sure if I'm building oiio correctly (the build instructions do not mention testsuite at all)
> Am I missing the correct branch? or should I apply the changes locally from the testsuite files to the /src folder
>
>
> Cheers
> Ran
>
>
> On 01/26/2015 11:20 AM, Larry Gritz wrote:
>> FYI, I have merged this fix into master.
>>
>> Since we're trying to push out a stable 1.5 release (today, ideally!), I didn't want to mess with that branch. Let's test this change in master for a while, and then if there is demand for a back-port, we can consider making the change in 1.5 as well.
>>
>> -- lg
>>
>>
>> On Jan 23, 2015, at 5:53 PM, ran sariel<***@theembassyvfx.com> wrote:
>>
>>> Thank you Larry, that's great news.
>>> ( I actually tried to set the --attrib for pixelAspectRatio, but it wasn't recognized by RV so I was assuming I got it wrong..)
>>>
>>> Cheers
>>> Ran
>>>
>>> On 01/23/2015 04:08 PM, Larry Gritz wrote:
>>>> OK, I did some digging, and it's a bit of a good news / bad news situation.
>>>>
>>>> Bad news: JPEG doesn't directly store the pixel aspect ratio in its metadata.
>>>>
>>>> Good news: JPEG does store "density" (dots per inch or cm in x and y), and so the pixel aspect ratio is implied to be ydensity/xdensity.
>>>>
>>>> Bad news: our JPEG reader (and writer) didn't handle xdensity and ydensity properly. (This is supposed to correspond to the standard OIIO metadata called "XResolution" and "YResolution", which are confusing names, but they are simply inherited from TIFF nomenclature.)
>>>>
>>>> Good news: I have a pull request (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and also tightens up the way we handle the mutual interactions of XResolution, YResolution, and PixelAspectRatio.
>>>>
>>>> Once this PR is approved and merged, you'll be able to set the implied pixel aspect ratio of a JPEG file like this:
>>>>
>>>> oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o nonsquare.jpg
>>>>
>>>>
>>>> On Jan 22, 2015, at 9:46 AM, ran sariel<***@theembassyvfx.com> wrote:
>>>>
>>>>> just change the metadata
>>>>>
>>>>> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>>>>>> aspect ratio
>>>>> --
>>>>> Ran Sariel
>>>>> CTO / Pipeline supervisor
>>>>> The Embassy VFX Inc.
>>>>> 177 West 7th Ave, 4th Floor
>>>>> Vancouver, BC
>>>>> Phone: [phone] ext. 244
>>>>>
>>>>> ***@theembassyvfx.com
>>>>>
>>>> --
>>>> Larry Gritz
>>>> ***@larrygritz.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> 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: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[ran sariel]

The build works fine so do the tests (for oiiotool at least).

looking at the resulting image from the conversion (in RV or nuke.)
I can see the exif/software info in RV
openImageIO 1.6.0dev: oiiotool in.exr --ch R,G,B --resize 50% --attrib
PixelAspectRatio 2.0 -o nonsquare.jpg
But the PixelAspect is not seen by RV.

oddly with or without passing the PixelAspectRation attrib I get the
same metaData on the jpeg i get
XResolution as 72/1
YResolution as 144/1

but no PixelAspectRatio written.

hence my assumption that I'm working with the wrong branch...


Ran





On 01/28/2015 03:41 PM, Larry Gritz wrote:
> I don't know what you mean. The patch I merged definitely had code changes as well as tests. It should all be in the current master.
>
> -- lg
>
>
> On Jan 27, 2015, at 9:43 AM, ran sariel<***@theembassyvfx.com> wrote:
>
>> Hi
>>
>> I downloaded and rebuilt master. seems that the changes are not in the main /src folder but in testsuite.
>> not sure if I'm building oiio correctly (the build instructions do not mention testsuite at all)
>> Am I missing the correct branch? or should I apply the changes locally from the testsuite files to the /src folder
>>
>>
>> Cheers
>> Ran
>>
>>
>> On 01/26/2015 11:20 AM, Larry Gritz wrote:
>>> FYI, I have merged this fix into master.
>>>
>>> Since we're trying to push out a stable 1.5 release (today, ideally!), I didn't want to mess with that branch. Let's test this change in master for a while, and then if there is demand for a back-port, we can consider making the change in 1.5 as well.
>>>
>>> -- lg
>>>
>>>
>>> On Jan 23, 2015, at 5:53 PM, ran sariel<***@theembassyvfx.com> wrote:
>>>
>>>> Thank you Larry, that's great news.
>>>> ( I actually tried to set the --attrib for pixelAspectRatio, but it wasn't recognized by RV so I was assuming I got it wrong..)
>>>>
>>>> Cheers
>>>> Ran
>>>>
>>>> On 01/23/2015 04:08 PM, Larry Gritz wrote:
>>>>> OK, I did some digging, and it's a bit of a good news / bad news situation.
>>>>>
>>>>> Bad news: JPEG doesn't directly store the pixel aspect ratio in its metadata.
>>>>>
>>>>> Good news: JPEG does store "density" (dots per inch or cm in x and y), and so the pixel aspect ratio is implied to be ydensity/xdensity.
>>>>>
>>>>> Bad news: our JPEG reader (and writer) didn't handle xdensity and ydensity properly. (This is supposed to correspond to the standard OIIO metadata called "XResolution" and "YResolution", which are confusing names, but they are simply inherited from TIFF nomenclature.)
>>>>>
>>>>> Good news: I have a pull request (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and also tightens up the way we handle the mutual interactions of XResolution, YResolution, and PixelAspectRatio.
>>>>>
>>>>> Once this PR is approved and merged, you'll be able to set the implied pixel aspect ratio of a JPEG file like this:
>>>>>
>>>>> oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o nonsquare.jpg
>>>>>
>>>>>
>>>>> On Jan 22, 2015, at 9:46 AM, ran sariel<***@theembassyvfx.com> wrote:
>>>>>
>>>>>> just change the metadata
>>>>>>
>>>>>> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>>>>>>> aspect ratio
>>>>>> --
>>>>>> Ran Sariel
>>>>>> CTO / Pipeline supervisor
>>>>>> The Embassy VFX Inc.
>>>>>> 177 West 7th Ave, 4th Floor
>>>>>> Vancouver, BC
>>>>>> Phone: [phone] ext. 244
>>>>>>
>>>>>> ***@theembassyvfx.com
>>>>>>
>>>>> --
>>>>> Larry Gritz
>>>>> ***@larrygritz.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> 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: [phone] ext. 244
>>>>
>>>> ***@theembassyvfx.com
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> --
>>> Larry Gritz
>>> ***@larrygritz.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> 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: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

I'm sorry, are you saying that rv doesn't tell you the aspect ratio? Or are you saying that OIIO (e.g. "oiiotool -info -v nonsquare.jpg") doesn't tell you the aspect ratio?



On Jan 28, 2015, at 4:42 PM, ran sariel <***@theembassyvfx.com> wrote:

> The build works fine so do the tests (for oiiotool at least).
>
> looking at the resulting image from the conversion (in RV or nuke.)
> I can see the exif/software info in RV
> openImageIO 1.6.0dev: oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio 2.0 -o nonsquare.jpg
> But the PixelAspect is not seen by RV.
>
> oddly with or without passing the PixelAspectRation attrib I get the same metaData on the jpeg i get
> XResolution as 72/1
> YResolution as 144/1
>
> but no PixelAspectRatio written.
>
> hence my assumption that I'm working with the wrong branch...
>
>
> Ran
>
>
>
>
>
> On 01/28/2015 03:41 PM, Larry Gritz wrote:
>> I don't know what you mean. The patch I merged definitely had code changes as well as tests. It should all be in the current master.
>>
>> -- lg
>>
>>
>> On Jan 27, 2015, at 9:43 AM, ran sariel<***@theembassyvfx.com> wrote:
>>
>>> Hi
>>>
>>> I downloaded and rebuilt master. seems that the changes are not in the main /src folder but in testsuite.
>>> not sure if I'm building oiio correctly (the build instructions do not mention testsuite at all)
>>> Am I missing the correct branch? or should I apply the changes locally from the testsuite files to the /src folder
>>>
>>>
>>> Cheers
>>> Ran
>>>
>>>
>>> On 01/26/2015 11:20 AM, Larry Gritz wrote:
>>>> FYI, I have merged this fix into master.
>>>>
>>>> Since we're trying to push out a stable 1.5 release (today, ideally!), I didn't want to mess with that branch. Let's test this change in master for a while, and then if there is demand for a back-port, we can consider making the change in 1.5 as well.
>>>>
>>>> -- lg
>>>>
>>>>
>>>> On Jan 23, 2015, at 5:53 PM, ran sariel<***@theembassyvfx.com> wrote:
>>>>
>>>>> Thank you Larry, that's great news.
>>>>> ( I actually tried to set the --attrib for pixelAspectRatio, but it wasn't recognized by RV so I was assuming I got it wrong..)
>>>>>
>>>>> Cheers
>>>>> Ran
>>>>>
>>>>> On 01/23/2015 04:08 PM, Larry Gritz wrote:
>>>>>> OK, I did some digging, and it's a bit of a good news / bad news situation.
>>>>>>
>>>>>> Bad news: JPEG doesn't directly store the pixel aspect ratio in its metadata.
>>>>>>
>>>>>> Good news: JPEG does store "density" (dots per inch or cm in x and y), and so the pixel aspect ratio is implied to be ydensity/xdensity.
>>>>>>
>>>>>> Bad news: our JPEG reader (and writer) didn't handle xdensity and ydensity properly. (This is supposed to correspond to the standard OIIO metadata called "XResolution" and "YResolution", which are confusing names, but they are simply inherited from TIFF nomenclature.)
>>>>>>
>>>>>> Good news: I have a pull request (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and also tightens up the way we handle the mutual interactions of XResolution, YResolution, and PixelAspectRatio.
>>>>>>
>>>>>> Once this PR is approved and merged, you'll be able to set the implied pixel aspect ratio of a JPEG file like this:
>>>>>>
>>>>>> oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o nonsquare.jpg
>>>>>>
>>>>>>
>>>>>> On Jan 22, 2015, at 9:46 AM, ran sariel<***@theembassyvfx.com> wrote:
>>>>>>
>>>>>>> just change the metadata
>>>>>>>
>>>>>>> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>>>>>>>> aspect ratio
>>>>>>> --
>>>>>>> Ran Sariel
>>>>>>> CTO / Pipeline supervisor
>>>>>>> The Embassy VFX Inc.
>>>>>>> 177 West 7th Ave, 4th Floor
>>>>>>> Vancouver, BC
>>>>>>> Phone: [phone] ext. 244
>>>>>>>
>>>>>>> ***@theembassyvfx.com
>>>>>>>
>>>>>> --
>>>>>> Larry Gritz
>>>>>> ***@larrygritz.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-***@lists.openimageio.org
>>>>>> 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: [phone] ext. 244
>>>>>
>>>>> ***@theembassyvfx.com
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> --
>>>> Larry Gritz
>>>> ***@larrygritz.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> 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: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[ran sariel]

oiiotool shows the aspect ratio attribute as written.

channel list: R, G, B
oiio:ColorSpace: "sRGB"
jpeg:subsampling: "4:2:0"
XResolution: 72
YResolution: 144
Exif:ColorSpace: 1
IPTC:OriginatingProgram: "OpenImageIO 1.6.0dev :oiiotool in.exr --ch
R,G,B --resize 50% --tocolorspace sRGB -attrib PixelAspectRatio 2.000000
-o nonsquare.jpg"
PixelAspectRatio: 2
ResolutionUnit: "none"

a 'working version' rendered from nuke with aspect ratio of 2 shows in
oiio as

working.jpg : 1047 x 858, 3 channel, uint8 jpeg
channel list: R, G, B
oiio:ColorSpace: "sRGB"
jpeg:subsampling: "4:4:4"
XResolution: 2400
YResolution: 1200
PixelAspectRatio: 0.5
ResolutionUnit: "none"

the difference is that working.jpg displays correctly in RV, (the aspect
ratio is read correctly from the file as 2.0)
but working.jpg isn't.


Ran





On 01/28/2015 05:04 PM, Larry Gritz wrote:
> I'm sorry, are you saying that rv doesn't tell you the aspect ratio? Or are you saying that OIIO (e.g. "oiiotool -info -v nonsquare.jpg") doesn't tell you the aspect ratio?
>
>
>
> On Jan 28, 2015, at 4:42 PM, ran sariel<***@theembassyvfx.com> wrote:
>
>> The build works fine so do the tests (for oiiotool at least).
>>
>> looking at the resulting image from the conversion (in RV or nuke.)
>> I can see the exif/software info in RV
>> openImageIO 1.6.0dev: oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio 2.0 -o nonsquare.jpg
>> But the PixelAspect is not seen by RV.
>>
>> oddly with or without passing the PixelAspectRation attrib I get the same metaData on the jpeg i get
>> XResolution as 72/1
>> YResolution as 144/1
>>
>> but no PixelAspectRatio written.
>>
>> hence my assumption that I'm working with the wrong branch...
>>
>>
>> Ran
>>
>>
>>
>>
>>
>> On 01/28/2015 03:41 PM, Larry Gritz wrote:
>>> I don't know what you mean. The patch I merged definitely had code changes as well as tests. It should all be in the current master.
>>>
>>> -- lg
>>>
>>>
>>> On Jan 27, 2015, at 9:43 AM, ran sariel<***@theembassyvfx.com> wrote:
>>>
>>>> Hi
>>>>
>>>> I downloaded and rebuilt master. seems that the changes are not in the main /src folder but in testsuite.
>>>> not sure if I'm building oiio correctly (the build instructions do not mention testsuite at all)
>>>> Am I missing the correct branch? or should I apply the changes locally from the testsuite files to the /src folder
>>>>
>>>>
>>>> Cheers
>>>> Ran
>>>>
>>>>
>>>> On 01/26/2015 11:20 AM, Larry Gritz wrote:
>>>>> FYI, I have merged this fix into master.
>>>>>
>>>>> Since we're trying to push out a stable 1.5 release (today, ideally!), I didn't want to mess with that branch. Let's test this change in master for a while, and then if there is demand for a back-port, we can consider making the change in 1.5 as well.
>>>>>
>>>>> -- lg
>>>>>
>>>>>
>>>>> On Jan 23, 2015, at 5:53 PM, ran sariel<***@theembassyvfx.com> wrote:
>>>>>
>>>>>> Thank you Larry, that's great news.
>>>>>> ( I actually tried to set the --attrib for pixelAspectRatio, but it wasn't recognized by RV so I was assuming I got it wrong..)
>>>>>>
>>>>>> Cheers
>>>>>> Ran
>>>>>>
>>>>>> On 01/23/2015 04:08 PM, Larry Gritz wrote:
>>>>>>> OK, I did some digging, and it's a bit of a good news / bad news situation.
>>>>>>>
>>>>>>> Bad news: JPEG doesn't directly store the pixel aspect ratio in its metadata.
>>>>>>>
>>>>>>> Good news: JPEG does store "density" (dots per inch or cm in x and y), and so the pixel aspect ratio is implied to be ydensity/xdensity.
>>>>>>>
>>>>>>> Bad news: our JPEG reader (and writer) didn't handle xdensity and ydensity properly. (This is supposed to correspond to the standard OIIO metadata called "XResolution" and "YResolution", which are confusing names, but they are simply inherited from TIFF nomenclature.)
>>>>>>>
>>>>>>> Good news: I have a pull request (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and also tightens up the way we handle the mutual interactions of XResolution, YResolution, and PixelAspectRatio.
>>>>>>>
>>>>>>> Once this PR is approved and merged, you'll be able to set the implied pixel aspect ratio of a JPEG file like this:
>>>>>>>
>>>>>>> oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o nonsquare.jpg
>>>>>>>
>>>>>>>
>>>>>>> On Jan 22, 2015, at 9:46 AM, ran sariel<***@theembassyvfx.com> wrote:
>>>>>>>
>>>>>>>> just change the metadata
>>>>>>>>
>>>>>>>> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>>>>>>>>> aspect ratio
>>>>>>>> --
>>>>>>>> Ran Sariel
>>>>>>>> CTO / Pipeline supervisor
>>>>>>>> The Embassy VFX Inc.
>>>>>>>> 177 West 7th Ave, 4th Floor
>>>>>>>> Vancouver, BC
>>>>>>>> Phone: [phone] ext. 244
>>>>>>>>
>>>>>>>> ***@theembassyvfx.com
>>>>>>>>
>>>>>>> --
>>>>>>> Larry Gritz
>>>>>>> ***@larrygritz.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> Oiio-***@lists.openimageio.org
>>>>>>> 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: [phone] ext. 244
>>>>>>
>>>>>> ***@theembassyvfx.com
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-***@lists.openimageio.org
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> --
>>>>> Larry Gritz
>>>>> ***@larrygritz.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> 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: [phone] ext. 244
>>>>
>>>> ***@theembassyvfx.com
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> --
>>> Larry Gritz
>>> ***@larrygritz.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> 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: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

(WARNING: this whole explanation depends on your viewing with a fixed-width font.)

I think maybe this is a disagreement between the different apps on what aspect ratio means.

I very well could have screwed this up, so let me explain my thinking, and people can tell me if it makes sense or if I botched it.

First of all, when we talk about the FRAME aspect ratio of a whole film image, we say the aspect is 1.85, or 16/9, or 2.35, or whatever, all of which are varying degrees of wider than they are tall. "Wider than tall" means a frame aspect ratio of greater than 1.0, "taller than wide" means a frame aspect ratio of less than 1.0. Right? So I'm gonna assume that the same is true of pixel aspect ratio.

OK, here's my cartoon of a 2x2 image with square pixels. Let's make up some densities, say the image is supposed to print 1 cm wide and 1 cm tall, so XResolution = 2, YResolution = 2, ResolutionUnit = "cm".

+---+---+ ^
| * | * | |
+---+---+ 1cm
| * | * | |
+---+---+ v

<- 1cm ->

We agree that this is a 1.0 aspect ratio, I assume. (I do hope you're viewing with a fixed width font)

So let's say we want to cut the density in half horizontally, giving us wide pixels.

+-------+ ^
| * | |
+-------+ 1cm
| * | |
+-------+ v

<- 1cm ->

There are still 2 vertical samples per cm, but only 1 horizontal sample per pixel. In other words, XResolution = 1, YResolution = 2.

What is the PixelAspectRatio?

Here's the shape of just one pixel:

+-------+
| |
+-------+

Remembering what we said about the aspect ratio of a whole frame, I would argue that the aspect ratio of a pixel that is wider than it is tall also should be a number greater than 1. For the above pixel, its PixelAspectRatio is 2.0, i.e. YResolution/XResolution. Also known as ydensity/xdensity, because note that in this terminology, "resolution" means "dots per length", like printer's resolution, NOT the faux "resolution" we use to describe the number of pixels in a whole image.

Nuke wrote an image that it says is 1047x858, with 2400 horizontal pixels per inch (let's say; the units are undefined), so the image is 0.43625 inches wide, and at a y density of 1200 pixels per inch, it should be 0.715 inches tall:

<-0.436"->
^ +--------+
| | |
| | |
0.715"| |
| | |
| | |
| | |
| | |
v +--------+

Is that what you expect? It's a tall skinny image?

Or, do you expect a wide image? If you expect wide, then I'm going to go out on a limb and claim that Nuke is totally botching the meaning of the density fields, and thus the aspect ratio. Maybe rv is also getting it backwards, either coincidentally having made the same mistake, or else purposely backwards in order to match Nuke's broken output.

Somebody let me know if I'm totally borked in my thinking about this. Maybe I'm the one who got it all wrong.

-- lg

PS. https://www.youtube.com/watch?v=Bt9zSfinwFA



On Jan 28, 2015, at 5:56 PM, ran sariel <***@theembassyvfx.com> wrote:

> oiiotool shows the aspect ratio attribute as written.
>
> channel list: R, G, B
> oiio:ColorSpace: "sRGB"
> jpeg:subsampling: "4:2:0"
> XResolution: 72
> YResolution: 144
> Exif:ColorSpace: 1
> IPTC:OriginatingProgram: "OpenImageIO 1.6.0dev :oiiotool in.exr --ch R,G,B --resize 50% --tocolorspace sRGB -attrib PixelAspectRatio 2.000000 -o nonsquare.jpg"
> PixelAspectRatio: 2
> ResolutionUnit: "none"
>
> a 'working version' rendered from nuke with aspect ratio of 2 shows in oiio as
>
> working.jpg : 1047 x 858, 3 channel, uint8 jpeg
> channel list: R, G, B
> oiio:ColorSpace: "sRGB"
> jpeg:subsampling: "4:4:4"
> XResolution: 2400
> YResolution: 1200
> PixelAspectRatio: 0.5
> ResolutionUnit: "none"
>
> the difference is that working.jpg displays correctly in RV, (the aspect ratio is read correctly from the file as 2.0)
> but working.jpg isn't.
>
>
> Ran
>
>
>
>
>
> On 01/28/2015 05:04 PM, Larry Gritz wrote:
>> I'm sorry, are you saying that rv doesn't tell you the aspect ratio? Or are you saying that OIIO (e.g. "oiiotool -info -v nonsquare.jpg") doesn't tell you the aspect ratio?
>>
>>
>>
>> On Jan 28, 2015, at 4:42 PM, ran sariel<***@theembassyvfx.com> wrote:
>>
>>> The build works fine so do the tests (for oiiotool at least).
>>>
>>> looking at the resulting image from the conversion (in RV or nuke.)
>>> I can see the exif/software info in RV
>>> openImageIO 1.6.0dev: oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio 2.0 -o nonsquare.jpg
>>> But the PixelAspect is not seen by RV.
>>>
>>> oddly with or without passing the PixelAspectRation attrib I get the same metaData on the jpeg i get
>>> XResolution as 72/1
>>> YResolution as 144/1
>>>
>>> but no PixelAspectRatio written.
>>>
>>> hence my assumption that I'm working with the wrong branch...
>>>
>>>
>>> Ran
>>>
>>>
>>>
>>>
>>>
>>> On 01/28/2015 03:41 PM, Larry Gritz wrote:
>>>> I don't know what you mean. The patch I merged definitely had code changes as well as tests. It should all be in the current master.
>>>>
>>>> -- lg
>>>>
>>>>
>>>> On Jan 27, 2015, at 9:43 AM, ran sariel<***@theembassyvfx.com> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I downloaded and rebuilt master. seems that the changes are not in the main /src folder but in testsuite.
>>>>> not sure if I'm building oiio correctly (the build instructions do not mention testsuite at all)
>>>>> Am I missing the correct branch? or should I apply the changes locally from the testsuite files to the /src folder
>>>>>
>>>>>
>>>>> Cheers
>>>>> Ran
>>>>>
>>>>>
>>>>> On 01/26/2015 11:20 AM, Larry Gritz wrote:
>>>>>> FYI, I have merged this fix into master.
>>>>>>
>>>>>> Since we're trying to push out a stable 1.5 release (today, ideally!), I didn't want to mess with that branch. Let's test this change in master for a while, and then if there is demand for a back-port, we can consider making the change in 1.5 as well.
>>>>>>
>>>>>> -- lg
>>>>>>
>>>>>>
>>>>>> On Jan 23, 2015, at 5:53 PM, ran sariel<***@theembassyvfx.com> wrote:
>>>>>>
>>>>>>> Thank you Larry, that's great news.
>>>>>>> ( I actually tried to set the --attrib for pixelAspectRatio, but it wasn't recognized by RV so I was assuming I got it wrong..)
>>>>>>>
>>>>>>> Cheers
>>>>>>> Ran
>>>>>>>
>>>>>>> On 01/23/2015 04:08 PM, Larry Gritz wrote:
>>>>>>>> OK, I did some digging, and it's a bit of a good news / bad news situation.
>>>>>>>>
>>>>>>>> Bad news: JPEG doesn't directly store the pixel aspect ratio in its metadata.
>>>>>>>>
>>>>>>>> Good news: JPEG does store "density" (dots per inch or cm in x and y), and so the pixel aspect ratio is implied to be ydensity/xdensity.
>>>>>>>>
>>>>>>>> Bad news: our JPEG reader (and writer) didn't handle xdensity and ydensity properly. (This is supposed to correspond to the standard OIIO metadata called "XResolution" and "YResolution", which are confusing names, but they are simply inherited from TIFF nomenclature.)
>>>>>>>>
>>>>>>>> Good news: I have a pull request (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and also tightens up the way we handle the mutual interactions of XResolution, YResolution, and PixelAspectRatio.
>>>>>>>>
>>>>>>>> Once this PR is approved and merged, you'll be able to set the implied pixel aspect ratio of a JPEG file like this:
>>>>>>>>
>>>>>>>> oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o nonsquare.jpg
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 22, 2015, at 9:46 AM, ran sariel<***@theembassyvfx.com> wrote:
>>>>>>>>
>>>>>>>>> just change the metadata
>>>>>>>>>
>>>>>>>>> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>>>>>>>>>> aspect ratio
>>>>>>>>> --
>>>>>>>>> Ran Sariel
>>>>>>>>> CTO / Pipeline supervisor
>>>>>>>>> The Embassy VFX Inc.
>>>>>>>>> 177 West 7th Ave, 4th Floor
>>>>>>>>> Vancouver, BC
>>>>>>>>> Phone: [phone] ext. 244
>>>>>>>>>
>>>>>>>>> ***@theembassyvfx.com
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Larry Gritz
>>>>>>>> ***@larrygritz.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> Oiio-***@lists.openimageio.org
>>>>>>>> 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: [phone] ext. 244
>>>>>>>
>>>>>>> ***@theembassyvfx.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> Oiio-***@lists.openimageio.org
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>> --
>>>>>> Larry Gritz
>>>>>> ***@larrygritz.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-***@lists.openimageio.org
>>>>>> 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: [phone] ext. 244
>>>>>
>>>>> ***@theembassyvfx.com
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> --
>>>> Larry Gritz
>>>> ***@larrygritz.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> 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: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[Nathan Rusch]

I think in this case the important thing to look at is the original command
that was run:




-Nathan

-----Original Message-----
From: Larry Gritz
Sent: Wednesday, January 28, 2015 11:04 PM
To: OpenImageIO developers
Subject: Re: [Oiio-dev] aspect ratio from oiiotool

(WARNING: this whole explanation depends on your viewing with a fixed-width
font.)

I think maybe this is a disagreement between the different apps on what
aspect ratio means.

I very well could have screwed this up, so let me explain my thinking, and
people can tell me if it makes sense or if I botched it.

First of all, when we talk about the FRAME aspect ratio of a whole film
image, we say the aspect is 1.85, or 16/9, or 2.35, or whatever, all of
which are varying degrees of wider than they are tall. "Wider than tall"
means a frame aspect ratio of greater than 1.0, "taller than wide" means a
frame aspect ratio of less than 1.0. Right? So I'm gonna assume that the
same is true of pixel aspect ratio.

OK, here's my cartoon of a 2x2 image with square pixels. Let's make up some
densities, say the image is supposed to print 1 cm wide and 1 cm tall, so
XResolution = 2, YResolution = 2, ResolutionUnit = "cm".

+---+---+ ^
| * | * | |
+---+---+ 1cm
| * | * | |
+---+---+ v

<- 1cm ->

We agree that this is a 1.0 aspect ratio, I assume. (I do hope you're
viewing with a fixed width font)

So let's say we want to cut the density in half horizontally, giving us wide
pixels.

+-------+ ^
| * | |
+-------+ 1cm
| * | |
+-------+ v

<- 1cm ->

There are still 2 vertical samples per cm, but only 1 horizontal sample per
pixel. In other words, XResolution = 1, YResolution = 2.

What is the PixelAspectRatio?

Here's the shape of just one pixel:

+-------+
| |
+-------+

Remembering what we said about the aspect ratio of a whole frame, I would
argue that the aspect ratio of a pixel that is wider than it is tall also
should be a number greater than 1. For the above pixel, its PixelAspectRatio
is 2.0, i.e. YResolution/XResolution. Also known as ydensity/xdensity,
because note that in this terminology, "resolution" means "dots per length",
like printer's resolution, NOT the faux "resolution" we use to describe the
number of pixels in a whole image.

Nuke wrote an image that it says is 1047x858, with 2400 horizontal pixels
per inch (let's say; the units are undefined), so the image is 0.43625
inches wide, and at a y density of 1200 pixels per inch, it should be 0.715
inches tall:

<-0.436"->
^ +--------+
| | |
| | |
0.715"| |
| | |
| | |
| | |
| | |
v +--------+

Is that what you expect? It's a tall skinny image?

Or, do you expect a wide image? If you expect wide, then I'm going to go
out on a limb and claim that Nuke is totally botching the meaning of the
density fields, and thus the aspect ratio. Maybe rv is also getting it
backwards, either coincidentally having made the same mistake, or else
purposely backwards in order to match Nuke's broken output.

Somebody let me know if I'm totally borked in my thinking about this. Maybe
I'm the one who got it all wrong.

-- lg

PS. https://www.youtube.com/watch?v=Bt9zSfinwFA



On Jan 28, 2015, at 5:56 PM, ran sariel <***@theembassyvfx.com> wrote:

> oiiotool shows the aspect ratio attribute as written.
>
> channel list: R, G, B
> oiio:ColorSpace: "sRGB"
> jpeg:subsampling: "4:2:0"
> XResolution: 72
> YResolution: 144
> Exif:ColorSpace: 1
> IPTC:OriginatingProgram: "OpenImageIO 1.6.0dev :oiiotool in.exr --ch
> R,G,B --resize 50% --tocolorspace sRGB -attrib PixelAspectRatio
> 2.000000 -o nonsquare.jpg"
> PixelAspectRatio: 2
> ResolutionUnit: "none"
>
> a 'working version' rendered from nuke with aspect ratio of 2 shows in
> oiio as
>
> working.jpg : 1047 x 858, 3 channel, uint8 jpeg
> channel list: R, G, B
> oiio:ColorSpace: "sRGB"
> jpeg:subsampling: "4:4:4"
> XResolution: 2400
> YResolution: 1200
> PixelAspectRatio: 0.5
> ResolutionUnit: "none"
>
> the difference is that working.jpg displays correctly in RV, (the aspect
> ratio is read correctly from the file as 2.0)
> but working.jpg isn't.
>
>
> Ran
>
>
>
>
>
> On 01/28/2015 05:04 PM, Larry Gritz wrote:
>> I'm sorry, are you saying that rv doesn't tell you the aspect ratio? Or
>> are you saying that OIIO (e.g. "oiiotool -info -v nonsquare.jpg") doesn't
>> tell you the aspect ratio?
>>
>>
>>
>> On Jan 28, 2015, at 4:42 PM, ran sariel<***@theembassyvfx.com>
>> wrote:
>>
>>> The build works fine so do the tests (for oiiotool at least).
>>>
>>> looking at the resulting image from the conversion (in RV or nuke.)
>>> I can see the exif/software info in RV
>>> openImageIO 1.6.0dev: oiiotool in.exr --ch R,G,B --resize 50% --attrib
>>> PixelAspectRatio 2.0 -o nonsquare.jpg
>>> But the PixelAspect is not seen by RV.
>>>
>>> oddly with or without passing the PixelAspectRation attrib I get the
>>> same metaData on the jpeg i get
>>> XResolution as 72/1
>>> YResolution as 144/1
>>>
>>> but no PixelAspectRatio written.
>>>
>>> hence my assumption that I'm working with the wrong branch...
>>>
>>>
>>> Ran
>>>
>>>
>>>
>>>
>>>
>>> On 01/28/2015 03:41 PM, Larry Gritz wrote:
>>>> I don't know what you mean. The patch I merged definitely had code
>>>> changes as well as tests. It should all be in the current master.
>>>>
>>>> -- lg
>>>>
>>>>
>>>> On Jan 27, 2015, at 9:43 AM, ran sariel<***@theembassyvfx.com>
>>>> wrote:
>>>>
>>>>> Hi
>>>>>
>>>>> I downloaded and rebuilt master. seems that the changes are not in the
>>>>> main /src folder but in testsuite.
>>>>> not sure if I'm building oiio correctly (the build instructions do not
>>>>> mention testsuite at all)
>>>>> Am I missing the correct branch? or should I apply the changes locally
>>>>> from the testsuite files to the /src folder
>>>>>
>>>>>
>>>>> Cheers
>>>>> Ran
>>>>>
>>>>>
>>>>> On 01/26/2015 11:20 AM, Larry Gritz wrote:
>>>>>> FYI, I have merged this fix into master.
>>>>>>
>>>>>> Since we're trying to push out a stable 1.5 release (today,
>>>>>> ideally!), I didn't want to mess with that branch. Let's test this
>>>>>> change in master for a while, and then if there is demand for a
>>>>>> back-port, we can consider making the change in 1.5 as well.
>>>>>>
>>>>>> -- lg
>>>>>>
>>>>>>
>>>>>> On Jan 23, 2015, at 5:53 PM, ran sariel<***@theembassyvfx.com>
>>>>>> wrote:
>>>>>>
>>>>>>> Thank you Larry, that's great news.
>>>>>>> ( I actually tried to set the --attrib for pixelAspectRatio, but it
>>>>>>> wasn't recognized by RV so I was assuming I got it wrong..)
>>>>>>>
>>>>>>> Cheers
>>>>>>> Ran
>>>>>>>
>>>>>>> On 01/23/2015 04:08 PM, Larry Gritz wrote:
>>>>>>>> OK, I did some digging, and it's a bit of a good news / bad news
>>>>>>>> situation.
>>>>>>>>
>>>>>>>> Bad news: JPEG doesn't directly store the pixel aspect ratio in its
>>>>>>>> metadata.
>>>>>>>>
>>>>>>>> Good news: JPEG does store "density" (dots per inch or cm in x and
>>>>>>>> y), and so the pixel aspect ratio is implied to be
>>>>>>>> ydensity/xdensity.
>>>>>>>>
>>>>>>>> Bad news: our JPEG reader (and writer) didn't handle xdensity and
>>>>>>>> ydensity properly. (This is supposed to correspond to the standard
>>>>>>>> OIIO metadata called "XResolution" and "YResolution", which are
>>>>>>>> confusing names, but they are simply inherited from TIFF
>>>>>>>> nomenclature.)
>>>>>>>>
>>>>>>>> Good news: I have a pull request
>>>>>>>> (https://github.com/OpenImageIO/oiio/pull/1042) that fixes it, and
>>>>>>>> also tightens up the way we handle the mutual interactions of
>>>>>>>> XResolution, YResolution, and PixelAspectRatio.
>>>>>>>>
>>>>>>>> Once this PR is approved and merged, you'll be able to set the
>>>>>>>> implied pixel aspect ratio of a JPEG file like this:
>>>>>>>>
>>>>>>>> oiiotool input.jpg -attrib "PixelAspectRatio" 1.1 -o nonsquare.jpg
>>>>>>>>
>>>>>>>>
>>>>>>>> On Jan 22, 2015, at 9:46 AM, ran sariel<***@theembassyvfx.com>
>>>>>>>> wrote:
>>>>>>>>
>>>>>>>>> just change the metadata
>>>>>>>>>
>>>>>>>>> On 01/22/2015 12:30 AM, Larry Gritz wrote:
>>>>>>>>>> aspect ratio
>>>>>>>>> --
>>>>>>>>> Ran Sariel
>>>>>>>>> CTO / Pipeline supervisor
>>>>>>>>> The Embassy VFX Inc.
>>>>>>>>> 177 West 7th Ave, 4th Floor
>>>>>>>>> Vancouver, BC
>>>>>>>>> Phone: [phone] ext. 244
>>>>>>>>>
>>>>>>>>> ***@theembassyvfx.com
>>>>>>>>>
>>>>>>>> --
>>>>>>>> Larry Gritz
>>>>>>>> ***@larrygritz.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> Oiio-***@lists.openimageio.org
>>>>>>>> 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: [phone] ext. 244
>>>>>>>
>>>>>>> ***@theembassyvfx.com
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> Oiio-***@lists.openimageio.org
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>> --
>>>>>> Larry Gritz
>>>>>> ***@larrygritz.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-***@lists.openimageio.org
>>>>>> 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: [phone] ext. 244
>>>>>
>>>>> ***@theembassyvfx.com
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> --
>>>> Larry Gritz
>>>> ***@larrygritz.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> 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: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[Nathan Rusch]

Sorry, the old Ctrl + Enter hotkey got me again...

I think an important thing here is to look at the command that was being
run:

oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio 2.0 -o
nonsquare.jpg

There is no non-uniform scaling being applied, and changing the pixel aspect
ratio of the image should not change its physical resolution at all. As
such, the result of this should be an image that, when viewed with proper
pixel aspect ratio correction, should appear to be twice as wide as the
original.

Now, about those metadata tags...

If you look at the EXIF tag definitions for XResolution and YResolution, the
language is a bit strange:

The number of pixels per <ResolutionUnit> in the <ImageWidth> direction.
[...]

If you reorient your thinking so the "resolution" of the image is actually
whatever <ResolutionUnit> is (defaults to inches), it starts to make some
sense. For a 512x512 square image at 72 dpi, the "resolution" is actually
7.111111 x 7.1111111.

Now, if the <XResolution> and <YResolution> values of that same image are
2400 and 1200, respectively, and we take the language of the EXIF tags
as-is, those 7.111111 inches of resolution are not going to be uniformly
mapped to screen pixels in both dimensions(remember, "pixels per
<ResolutionUnit>"). Instead, the result will be a "pixel image" twice as
wide as it is tall.

In practice, the resolution tags are treated as a ratio, and the image's
pixel resolution is read directly from the file.

Finally, even if you disagree with all of this (which I wouldn't really
fault you for), the fact is that Nuke, RV, and Adobe products currently all
agree on how they should be handled, so I think it might be best to try and
stay consistent.


-Nathan



-----Original Message-----
From: Larry Gritz
Sent: Wednesday, January 28, 2015 11:04 PM
To: OpenImageIO developers
Subject: Re: [Oiio-dev] aspect ratio from oiiotool

(WARNING: this whole explanation depends on your viewing with a fixed-width
font.)

I think maybe this is a disagreement between the different apps on what
aspect ratio means.

I very well could have screwed this up, so let me explain my thinking, and
people can tell me if it makes sense or if I botched it.

First of all, when we talk about the FRAME aspect ratio of a whole film
image, we say the aspect is 1.85, or 16/9, or 2.35, or whatever, all of
which are varying degrees of wider than they are tall. "Wider than tall"
means a frame aspect ratio of greater than 1.0, "taller than wide" means a
frame aspect ratio of less than 1.0. Right? So I'm gonna assume that the
same is true of pixel aspect ratio.

OK, here's my cartoon of a 2x2 image with square pixels. Let's make up some
densities, say the image is supposed to print 1 cm wide and 1 cm tall, so
XResolution = 2, YResolution = 2, ResolutionUnit = "cm".

+---+---+ ^
| * | * | |
+---+---+ 1cm
| * | * | |
+---+---+ v

<- 1cm ->

We agree that this is a 1.0 aspect ratio, I assume. (I do hope you're
viewing with a fixed width font)

So let's say we want to cut the density in half horizontally, giving us wide
pixels.

+-------+ ^
| * | |
+-------+ 1cm
| * | |
+-------+ v

<- 1cm ->

There are still 2 vertical samples per cm, but only 1 horizontal sample per
pixel. In other words, XResolution = 1, YResolution = 2.

What is the PixelAspectRatio?

Here's the shape of just one pixel:

+-------+
| |
+-------+

Remembering what we said about the aspect ratio of a whole frame, I would
argue that the aspect ratio of a pixel that is wider than it is tall also
should be a number greater than 1. For the above pixel, its PixelAspectRatio
is 2.0, i.e. YResolution/XResolution. Also known as ydensity/xdensity,
because note that in this terminology, "resolution" means "dots per length",
like printer's resolution, NOT the faux "resolution" we use to describe the
number of pixels in a whole image.

Nuke wrote an image that it says is 1047x858, with 2400 horizontal pixels
per inch (let's say; the units are undefined), so the image is 0.43625
inches wide, and at a y density of 1200 pixels per inch, it should be 0.715
inches tall:

<-0.436"->
^ +--------+
| | |
| | |
0.715"| |
| | |
| | |
| | |
| | |
v +--------+

Is that what you expect? It's a tall skinny image?

Or, do you expect a wide image? If you expect wide, then I'm going to go
out on a limb and claim that Nuke is totally botching the meaning of the
density fields, and thus the aspect ratio. Maybe rv is also getting it
backwards, either coincidentally having made the same mistake, or else
purposely backwards in order to match Nuke's broken output.

Somebody let me know if I'm totally borked in my thinking about this. Maybe
I'm the one who got it all wrong.

-- lg

PS. https://www.youtube.com/watch?v=Bt9zSfinwFA

[ran sariel]

actually in this case, the resize is not changing the result,
running the conversion without the resize on the input image (exr with
pixelAspectRatio 2 - according to both RV and oiiotool.)
I get a jpeg image that is not recognized by RV as having
PixelAspectRatio of 2.
oiiotool recognizes that the image has a PixelAspectRatio attribute with
a value of 2.
I guess other packages are expecting something different than that
attribute, RV shows the density as 2400x1200 for the file written from
nuke. and as 1 for the file converted by oiiotool.







On 01/29/2015 09:58 AM, Nathan Rusch wrote:
> Sorry, the old Ctrl + Enter hotkey got me again...
>
> I think an important thing here is to look at the command that was
> being run:
>
> oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio
> 2.0 -o nonsquare.jpg
>
> There is no non-uniform scaling being applied, and changing the pixel
> aspect ratio of the image should not change its physical resolution at
> all. As such, the result of this should be an image that, when viewed
> with proper pixel aspect ratio correction, should appear to be twice
> as wide as the original.
>
> Now, about those metadata tags...
>
> If you look at the EXIF tag definitions for XResolution and
> YResolution, the language is a bit strange:
>
> The number of pixels per <ResolutionUnit> in the <ImageWidth>
> direction. [...]
>
> If you reorient your thinking so the "resolution" of the image is
> actually whatever <ResolutionUnit> is (defaults to inches), it starts
> to make some sense. For a 512x512 square image at 72 dpi, the
> "resolution" is actually 7.111111 x 7.1111111.
>
> Now, if the <XResolution> and <YResolution> values of that same image
> are 2400 and 1200, respectively, and we take the language of the EXIF
> tags as-is, those 7.111111 inches of resolution are not going to be
> uniformly mapped to screen pixels in both dimensions(remember, "pixels
> per <ResolutionUnit>"). Instead, the result will be a "pixel image"
> twice as wide as it is tall.
>
> In practice, the resolution tags are treated as a ratio, and the
> image's pixel resolution is read directly from the file.
>
> Finally, even if you disagree with all of this (which I wouldn't
> really fault you for), the fact is that Nuke, RV, and Adobe products
> currently all agree on how they should be handled, so I think it might
> be best to try and stay consistent.
>
>
> -Nathan
>
>
>
> -----Original Message----- From: Larry Gritz
> Sent: Wednesday, January 28, 2015 11:04 PM
> To: OpenImageIO developers
> Subject: Re: [Oiio-dev] aspect ratio from oiiotool
>
> (WARNING: this whole explanation depends on your viewing with a
> fixed-width font.)
>
> I think maybe this is a disagreement between the different apps on
> what aspect ratio means.
>
> I very well could have screwed this up, so let me explain my thinking,
> and people can tell me if it makes sense or if I botched it.
>
> First of all, when we talk about the FRAME aspect ratio of a whole
> film image, we say the aspect is 1.85, or 16/9, or 2.35, or whatever,
> all of which are varying degrees of wider than they are tall. "Wider
> than tall" means a frame aspect ratio of greater than 1.0, "taller
> than wide" means a frame aspect ratio of less than 1.0. Right? So I'm
> gonna assume that the same is true of pixel aspect ratio.
>
> OK, here's my cartoon of a 2x2 image with square pixels. Let's make up
> some densities, say the image is supposed to print 1 cm wide and 1 cm
> tall, so XResolution = 2, YResolution = 2, ResolutionUnit = "cm".
>
> +---+---+ ^
> | * | * | |
> +---+---+ 1cm
> | * | * | |
> +---+---+ v
>
> <- 1cm ->
>
> We agree that this is a 1.0 aspect ratio, I assume. (I do hope you're
> viewing with a fixed width font)
>
> So let's say we want to cut the density in half horizontally, giving
> us wide pixels.
>
> +-------+ ^
> | * | |
> +-------+ 1cm
> | * | |
> +-------+ v
>
> <- 1cm ->
>
> There are still 2 vertical samples per cm, but only 1 horizontal
> sample per pixel. In other words, XResolution = 1, YResolution = 2.
>
> What is the PixelAspectRatio?
>
> Here's the shape of just one pixel:
>
> +-------+
> | |
> +-------+
>
> Remembering what we said about the aspect ratio of a whole frame, I
> would argue that the aspect ratio of a pixel that is wider than it is
> tall also should be a number greater than 1. For the above pixel, its
> PixelAspectRatio is 2.0, i.e. YResolution/XResolution. Also known as
> ydensity/xdensity, because note that in this terminology, "resolution"
> means "dots per length", like printer's resolution, NOT the faux
> "resolution" we use to describe the number of pixels in a whole image.
>
> Nuke wrote an image that it says is 1047x858, with 2400 horizontal
> pixels per inch (let's say; the units are undefined), so the image is
> 0.43625 inches wide, and at a y density of 1200 pixels per inch, it
> should be 0.715 inches tall:
>
> <-0.436"->
> ^ +--------+
> | | |
> | | |
> 0.715"| |
> | | |
> | | |
> | | |
> | | |
> v +--------+
>
> Is that what you expect? It's a tall skinny image?
>
> Or, do you expect a wide image? If you expect wide, then I'm going to
> go out on a limb and claim that Nuke is totally botching the meaning
> of the density fields, and thus the aspect ratio. Maybe rv is also
> getting it backwards, either coincidentally having made the same
> mistake, or else purposely backwards in order to match Nuke's broken
> output.
>
> Somebody let me know if I'm totally borked in my thinking about this.
> Maybe I'm the one who got it all wrong.
>
> -- lg
>
> PS. https://www.youtube.com/watch?v=Bt9zSfinwFA
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

Sorry for the delay, I was tied up ALL day today.

I'm still not clear on the basics of the situation.

Is the image supposed to look wider than it is tall?

Are the individual pixels in the image supposed to be wider than they are tall?



On Jan 29, 2015, at 10:56 AM, ran sariel <***@theembassyvfx.com> wrote:

> actually in this case, the resize is not changing the result,
> running the conversion without the resize on the input image (exr with pixelAspectRatio 2 - according to both RV and oiiotool.)
> I get a jpeg image that is not recognized by RV as having PixelAspectRatio of 2.
> oiiotool recognizes that the image has a PixelAspectRatio attribute with a value of 2.
> I guess other packages are expecting something different than that attribute, RV shows the density as 2400x1200 for the file written from nuke. and as 1 for the file converted by oiiotool.
>
>
>
>
>
>
>
> On 01/29/2015 09:58 AM, Nathan Rusch wrote:
>> Sorry, the old Ctrl + Enter hotkey got me again...
>>
>> I think an important thing here is to look at the command that was being run:
>>
>> oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio 2.0 -o nonsquare.jpg
>>
>> There is no non-uniform scaling being applied, and changing the pixel aspect ratio of the image should not change its physical resolution at all. As such, the result of this should be an image that, when viewed with proper pixel aspect ratio correction, should appear to be twice as wide as the original.
>>
>> Now, about those metadata tags...
>>
>> If you look at the EXIF tag definitions for XResolution and YResolution, the language is a bit strange:
>>
>> The number of pixels per <ResolutionUnit> in the <ImageWidth> direction. [...]
>>
>> If you reorient your thinking so the "resolution" of the image is actually whatever <ResolutionUnit> is (defaults to inches), it starts to make some sense. For a 512x512 square image at 72 dpi, the "resolution" is actually 7.111111 x 7.1111111.
>>
>> Now, if the <XResolution> and <YResolution> values of that same image are 2400 and 1200, respectively, and we take the language of the EXIF tags as-is, those 7.111111 inches of resolution are not going to be uniformly mapped to screen pixels in both dimensions(remember, "pixels per <ResolutionUnit>"). Instead, the result will be a "pixel image" twice as wide as it is tall.
>>
>> In practice, the resolution tags are treated as a ratio, and the image's pixel resolution is read directly from the file.
>>
>> Finally, even if you disagree with all of this (which I wouldn't really fault you for), the fact is that Nuke, RV, and Adobe products currently all agree on how they should be handled, so I think it might be best to try and stay consistent.
>>
>>
>> -Nathan
>>
>>
>>
>> -----Original Message----- From: Larry Gritz
>> Sent: Wednesday, January 28, 2015 11:04 PM
>> To: OpenImageIO developers
>> Subject: Re: [Oiio-dev] aspect ratio from oiiotool
>>
>> (WARNING: this whole explanation depends on your viewing with a fixed-width font.)
>>
>> I think maybe this is a disagreement between the different apps on what aspect ratio means.
>>
>> I very well could have screwed this up, so let me explain my thinking, and people can tell me if it makes sense or if I botched it.
>>
>> First of all, when we talk about the FRAME aspect ratio of a whole film image, we say the aspect is 1.85, or 16/9, or 2.35, or whatever, all of which are varying degrees of wider than they are tall. "Wider than tall" means a frame aspect ratio of greater than 1.0, "taller than wide" means a frame aspect ratio of less than 1.0. Right? So I'm gonna assume that the same is true of pixel aspect ratio.
>>
>> OK, here's my cartoon of a 2x2 image with square pixels. Let's make up some densities, say the image is supposed to print 1 cm wide and 1 cm tall, so XResolution = 2, YResolution = 2, ResolutionUnit = "cm".
>>
>> +---+---+ ^
>> | * | * | |
>> +---+---+ 1cm
>> | * | * | |
>> +---+---+ v
>>
>> <- 1cm ->
>>
>> We agree that this is a 1.0 aspect ratio, I assume. (I do hope you're viewing with a fixed width font)
>>
>> So let's say we want to cut the density in half horizontally, giving us wide pixels.
>>
>> +-------+ ^
>> | * | |
>> +-------+ 1cm
>> | * | |
>> +-------+ v
>>
>> <- 1cm ->
>>
>> There are still 2 vertical samples per cm, but only 1 horizontal sample per pixel. In other words, XResolution = 1, YResolution = 2.
>>
>> What is the PixelAspectRatio?
>>
>> Here's the shape of just one pixel:
>>
>> +-------+
>> | |
>> +-------+
>>
>> Remembering what we said about the aspect ratio of a whole frame, I would argue that the aspect ratio of a pixel that is wider than it is tall also should be a number greater than 1. For the above pixel, its PixelAspectRatio is 2.0, i.e. YResolution/XResolution. Also known as ydensity/xdensity, because note that in this terminology, "resolution" means "dots per length", like printer's resolution, NOT the faux "resolution" we use to describe the number of pixels in a whole image.
>>
>> Nuke wrote an image that it says is 1047x858, with 2400 horizontal pixels per inch (let's say; the units are undefined), so the image is 0.43625 inches wide, and at a y density of 1200 pixels per inch, it should be 0.715 inches tall:
>>
>> <-0.436"->
>> ^ +--------+
>> | | |
>> | | |
>> 0.715"| |
>> | | |
>> | | |
>> | | |
>> | | |
>> v +--------+
>>
>> Is that what you expect? It's a tall skinny image?
>>
>> Or, do you expect a wide image? If you expect wide, then I'm going to go out on a limb and claim that Nuke is totally botching the meaning of the density fields, and thus the aspect ratio. Maybe rv is also getting it backwards, either coincidentally having made the same mistake, or else purposely backwards in order to match Nuke's broken output.
>>
>> Somebody let me know if I'm totally borked in my thinking about this. Maybe I'm the one who got it all wrong.
>>
>> -- lg
>>
>> PS. https://www.youtube.com/watch?v=Bt9zSfinwFA
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[ran sariel]

Hi Larry

yes with PixelAspectRatio of 2 a square image will look twice as wide,
The individual pixesl are wider than they are tall.


On 01/29/2015 11:16 PM, Larry Gritz wrote:
> Sorry for the delay, I was tied up ALL day today.
>
> I'm still not clear on the basics of the situation.
>
> Is the image supposed to look wider than it is tall?
>
> Are the individual pixels in the image supposed to be wider than they are tall?
>
>
>
> On Jan 29, 2015, at 10:56 AM, ran sariel<***@theembassyvfx.com> wrote:
>
>> actually in this case, the resize is not changing the result,
>> running the conversion without the resize on the input image (exr with pixelAspectRatio 2 - according to both RV and oiiotool.)
>> I get a jpeg image that is not recognized by RV as having PixelAspectRatio of 2.
>> oiiotool recognizes that the image has a PixelAspectRatio attribute with a value of 2.
>> I guess other packages are expecting something different than that attribute, RV shows the density as 2400x1200 for the file written from nuke. and as 1 for the file converted by oiiotool.
>>
>>
>>
>>
>>
>>
>>
>> On 01/29/2015 09:58 AM, Nathan Rusch wrote:
>>> Sorry, the old Ctrl + Enter hotkey got me again...
>>>
>>> I think an important thing here is to look at the command that was being run:
>>>
>>> oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio 2.0 -o nonsquare.jpg
>>>
>>> There is no non-uniform scaling being applied, and changing the pixel aspect ratio of the image should not change its physical resolution at all. As such, the result of this should be an image that, when viewed with proper pixel aspect ratio correction, should appear to be twice as wide as the original.
>>>
>>> Now, about those metadata tags...
>>>
>>> If you look at the EXIF tag definitions for XResolution and YResolution, the language is a bit strange:
>>>
>>> The number of pixels per<ResolutionUnit> in the<ImageWidth> direction. [...]
>>>
>>> If you reorient your thinking so the "resolution" of the image is actually whatever<ResolutionUnit> is (defaults to inches), it starts to make some sense. For a 512x512 square image at 72 dpi, the "resolution" is actually 7.111111 x 7.1111111.
>>>
>>> Now, if the<XResolution> and<YResolution> values of that same image are 2400 and 1200, respectively, and we take the language of the EXIF tags as-is, those 7.111111 inches of resolution are not going to be uniformly mapped to screen pixels in both dimensions(remember, "pixels per<ResolutionUnit>"). Instead, the result will be a "pixel image" twice as wide as it is tall.
>>>
>>> In practice, the resolution tags are treated as a ratio, and the image's pixel resolution is read directly from the file.
>>>
>>> Finally, even if you disagree with all of this (which I wouldn't really fault you for), the fact is that Nuke, RV, and Adobe products currently all agree on how they should be handled, so I think it might be best to try and stay consistent.
>>>
>>>
>>> -Nathan
>>>
>>>
>>>
>>> -----Original Message----- From: Larry Gritz
>>> Sent: Wednesday, January 28, 2015 11:04 PM
>>> To: OpenImageIO developers
>>> Subject: Re: [Oiio-dev] aspect ratio from oiiotool
>>>
>>> (WARNING: this whole explanation depends on your viewing with a fixed-width font.)
>>>
>>> I think maybe this is a disagreement between the different apps on what aspect ratio means.
>>>
>>> I very well could have screwed this up, so let me explain my thinking, and people can tell me if it makes sense or if I botched it.
>>>
>>> First of all, when we talk about the FRAME aspect ratio of a whole film image, we say the aspect is 1.85, or 16/9, or 2.35, or whatever, all of which are varying degrees of wider than they are tall. "Wider than tall" means a frame aspect ratio of greater than 1.0, "taller than wide" means a frame aspect ratio of less than 1.0. Right? So I'm gonna assume that the same is true of pixel aspect ratio.
>>>
>>> OK, here's my cartoon of a 2x2 image with square pixels. Let's make up some densities, say the image is supposed to print 1 cm wide and 1 cm tall, so XResolution = 2, YResolution = 2, ResolutionUnit = "cm".
>>>
>>> +---+---+ ^
>>> | * | * | |
>>> +---+---+ 1cm
>>> | * | * | |
>>> +---+---+ v
>>>
>>> <- 1cm ->
>>>
>>> We agree that this is a 1.0 aspect ratio, I assume. (I do hope you're viewing with a fixed width font)
>>>
>>> So let's say we want to cut the density in half horizontally, giving us wide pixels.
>>>
>>> +-------+ ^
>>> | * | |
>>> +-------+ 1cm
>>> | * | |
>>> +-------+ v
>>>
>>> <- 1cm ->
>>>
>>> There are still 2 vertical samples per cm, but only 1 horizontal sample per pixel. In other words, XResolution = 1, YResolution = 2.
>>>
>>> What is the PixelAspectRatio?
>>>
>>> Here's the shape of just one pixel:
>>>
>>> +-------+
>>> | |
>>> +-------+
>>>
>>> Remembering what we said about the aspect ratio of a whole frame, I would argue that the aspect ratio of a pixel that is wider than it is tall also should be a number greater than 1. For the above pixel, its PixelAspectRatio is 2.0, i.e. YResolution/XResolution. Also known as ydensity/xdensity, because note that in this terminology, "resolution" means "dots per length", like printer's resolution, NOT the faux "resolution" we use to describe the number of pixels in a whole image.
>>>
>>> Nuke wrote an image that it says is 1047x858, with 2400 horizontal pixels per inch (let's say; the units are undefined), so the image is 0.43625 inches wide, and at a y density of 1200 pixels per inch, it should be 0.715 inches tall:
>>>
>>> <-0.436"->
>>> ^ +--------+
>>> | | |
>>> | | |
>>> 0.715"| |
>>> | | |
>>> | | |
>>> | | |
>>> | | |
>>> v +--------+
>>>
>>> Is that what you expect? It's a tall skinny image?
>>>
>>> Or, do you expect a wide image? If you expect wide, then I'm going to go out on a limb and claim that Nuke is totally botching the meaning of the density fields, and thus the aspect ratio. Maybe rv is also getting it backwards, either coincidentally having made the same mistake, or else purposely backwards in order to match Nuke's broken output.
>>>
>>> Somebody let me know if I'm totally borked in my thinking about this. Maybe I'm the one who got it all wrong.
>>>
>>> -- lg
>>>
>>> PS. https://www.youtube.com/watch?v=Bt9zSfinwFA
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> 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: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

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").

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.

Can you send me (via private email is fine) one of those images that comes from Nuke so I can inspect exactly what's going on?

Just to clarify again, there is no such thing as "PixelAspectRatio" metadata in a JPEG file (whereas there is in OpenEXR, for example). It just doesn't exist as such, in JPEG files. The pixel aspect is implied by the x and y density values. OIIO tries to shield you from this, computing the ratio and reporting it as PixelAspectRatio, and also if you give it a PixelAspectRatio, it will make sure to output densities that give the right ratio.

-- lg


On Jan 30, 2015, at 10:34 AM, ran sariel <***@theembassyvfx.com> wrote:

> Hi Larry
>
> yes with PixelAspectRatio of 2 a square image will look twice as wide,
> The individual pixesl are wider than they are tall.
>
>
> On 01/29/2015 11:16 PM, Larry Gritz wrote:
>> Sorry for the delay, I was tied up ALL day today.
>>
>> I'm still not clear on the basics of the situation.
>>
>> Is the image supposed to look wider than it is tall?
>>
>> Are the individual pixels in the image supposed to be wider than they are tall?
>>
>>
>>
>> On Jan 29, 2015, at 10:56 AM, ran sariel<***@theembassyvfx.com> wrote:
>>
>>> actually in this case, the resize is not changing the result,
>>> running the conversion without the resize on the input image (exr with pixelAspectRatio 2 - according to both RV and oiiotool.)
>>> I get a jpeg image that is not recognized by RV as having PixelAspectRatio of 2.
>>> oiiotool recognizes that the image has a PixelAspectRatio attribute with a value of 2.
>>> I guess other packages are expecting something different than that attribute, RV shows the density as 2400x1200 for the file written from nuke. and as 1 for the file converted by oiiotool.
>>>
>>>
>>>
>>>
>>>
>>>
>>>
>>> On 01/29/2015 09:58 AM, Nathan Rusch wrote:
>>>> Sorry, the old Ctrl + Enter hotkey got me again...
>>>>
>>>> I think an important thing here is to look at the command that was being run:
>>>>
>>>> oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio 2.0 -o nonsquare.jpg
>>>>
>>>> There is no non-uniform scaling being applied, and changing the pixel aspect ratio of the image should not change its physical resolution at all. As such, the result of this should be an image that, when viewed with proper pixel aspect ratio correction, should appear to be twice as wide as the original.
>>>>
>>>> Now, about those metadata tags...
>>>>
>>>> If you look at the EXIF tag definitions for XResolution and YResolution, the language is a bit strange:
>>>>
>>>> The number of pixels per<ResolutionUnit> in the<ImageWidth> direction. [...]
>>>>
>>>> If you reorient your thinking so the "resolution" of the image is actually whatever<ResolutionUnit> is (defaults to inches), it starts to make some sense. For a 512x512 square image at 72 dpi, the "resolution" is actually 7.111111 x 7.1111111.
>>>>
>>>> Now, if the<XResolution> and<YResolution> values of that same image are 2400 and 1200, respectively, and we take the language of the EXIF tags as-is, those 7.111111 inches of resolution are not going to be uniformly mapped to screen pixels in both dimensions(remember, "pixels per<ResolutionUnit>"). Instead, the result will be a "pixel image" twice as wide as it is tall.
>>>>
>>>> In practice, the resolution tags are treated as a ratio, and the image's pixel resolution is read directly from the file.
>>>>
>>>> Finally, even if you disagree with all of this (which I wouldn't really fault you for), the fact is that Nuke, RV, and Adobe products currently all agree on how they should be handled, so I think it might be best to try and stay consistent.
>>>>
>>>>
>>>> -Nathan
>>>>
>>>>
>>>>
>>>> -----Original Message----- From: Larry Gritz
>>>> Sent: Wednesday, January 28, 2015 11:04 PM
>>>> To: OpenImageIO developers
>>>> Subject: Re: [Oiio-dev] aspect ratio from oiiotool
>>>>
>>>> (WARNING: this whole explanation depends on your viewing with a fixed-width font.)
>>>>
>>>> I think maybe this is a disagreement between the different apps on what aspect ratio means.
>>>>
>>>> I very well could have screwed this up, so let me explain my thinking, and people can tell me if it makes sense or if I botched it.
>>>>
>>>> First of all, when we talk about the FRAME aspect ratio of a whole film image, we say the aspect is 1.85, or 16/9, or 2.35, or whatever, all of which are varying degrees of wider than they are tall. "Wider than tall" means a frame aspect ratio of greater than 1.0, "taller than wide" means a frame aspect ratio of less than 1.0. Right? So I'm gonna assume that the same is true of pixel aspect ratio.
>>>>
>>>> OK, here's my cartoon of a 2x2 image with square pixels. Let's make up some densities, say the image is supposed to print 1 cm wide and 1 cm tall, so XResolution = 2, YResolution = 2, ResolutionUnit = "cm".
>>>>
>>>> +---+---+ ^
>>>> | * | * | |
>>>> +---+---+ 1cm
>>>> | * | * | |
>>>> +---+---+ v
>>>>
>>>> <- 1cm ->
>>>>
>>>> We agree that this is a 1.0 aspect ratio, I assume. (I do hope you're viewing with a fixed width font)
>>>>
>>>> So let's say we want to cut the density in half horizontally, giving us wide pixels.
>>>>
>>>> +-------+ ^
>>>> | * | |
>>>> +-------+ 1cm
>>>> | * | |
>>>> +-------+ v
>>>>
>>>> <- 1cm ->
>>>>
>>>> There are still 2 vertical samples per cm, but only 1 horizontal sample per pixel. In other words, XResolution = 1, YResolution = 2.
>>>>
>>>> What is the PixelAspectRatio?
>>>>
>>>> Here's the shape of just one pixel:
>>>>
>>>> +-------+
>>>> | |
>>>> +-------+
>>>>
>>>> Remembering what we said about the aspect ratio of a whole frame, I would argue that the aspect ratio of a pixel that is wider than it is tall also should be a number greater than 1. For the above pixel, its PixelAspectRatio is 2.0, i.e. YResolution/XResolution. Also known as ydensity/xdensity, because note that in this terminology, "resolution" means "dots per length", like printer's resolution, NOT the faux "resolution" we use to describe the number of pixels in a whole image.
>>>>
>>>> Nuke wrote an image that it says is 1047x858, with 2400 horizontal pixels per inch (let's say; the units are undefined), so the image is 0.43625 inches wide, and at a y density of 1200 pixels per inch, it should be 0.715 inches tall:
>>>>
>>>> <-0.436"->
>>>> ^ +--------+
>>>> | | |
>>>> | | |
>>>> 0.715"| |
>>>> | | |
>>>> | | |
>>>> | | |
>>>> | | |
>>>> v +--------+
>>>>
>>>> Is that what you expect? It's a tall skinny image?
>>>>
>>>> Or, do you expect a wide image? If you expect wide, then I'm going to go out on a limb and claim that Nuke is totally botching the meaning of the density fields, and thus the aspect ratio. Maybe rv is also getting it backwards, either coincidentally having made the same mistake, or else purposely backwards in order to match Nuke's broken output.
>>>>
>>>> Somebody let me know if I'm totally borked in my thinking about this. Maybe I'm the one who got it all wrong.
>>>>
>>>> -- lg
>>>>
>>>> PS. https://www.youtube.com/watch?v=Bt9zSfinwFA
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> 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: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[Larry Gritz]

On Jan 30, 2015, at 11:17 AM, Larry Gritz <***@larrygritz.com> 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").

I hope it was clear that I meant, "if pixels are wider than they are small, xDensity should be smaller than yDensity."

I wrote xDensity twice.


--
Larry Gritz
***@larrygritz.com

[Nathan Rusch]

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

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

And here is the complete tag definition for ResolutionUnit (taken from
http://www.exiv2.org/Exif2-2.PDF):

---------------------------
ResolutionUnit

The unit for measuring XResolution and YResolution. The same unit is used
for both XResolution and YResolution.
If the image resolution in unknown, 2 (inches) is designated.

Tag = 296 (128.H)
Type = SHORT
Count = 1
Default = 2
2 = inches
3 = centimeters
Other = reserved
---------------------------

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.


-Nathan

[Larry Gritz]

On Jan 30, 2015, at 11:44 AM, Nathan Rusch <***@gmail.com> 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
***@larrygritz.com

[Larry Gritz]

On Jan 30, 2015, at 11:56 AM, Larry Gritz <***@larrygritz.com> wrote:

> Once again, XResolution < YResolution means short wide pixels, XResolution > XResolution means tall skinny pixels.
>

Dammit, again with the bad fingers.

That should read:

XResolution < YResolution means short wide pixels, XResolution > YResolution means tall skinny pixels.


--
Larry Gritz
***@larrygritz.com

[Nathan Rusch]

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 <***@gmail.com> 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
***@larrygritz.com

[Larry Gritz]

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 <***@gmail.com> 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 <***@gmail.com> 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
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[Larry Gritz]

More grist for the mill: http://www.cipa.jp/std/documents/e/DC-008-2012_E.pdf

If you search the 2012 Exif specification for "aspect", the only mention is this stark comment:

4.4.2 Pixel Aspect

Image data shall be recorded as square pixels with a pixel aspect ratio of 1:1. This
specification is applied similarly to thumbnails.

Eew, that sort of implies that, as least as far as Exif is concerned, there is no provision whatsoever for non-square pixels. I'm not sure what conclusions to draw from that. I'm also not sure why they have separate XResolution and YResolution fields in Exif, if they disallow the very existence of non-square pixels. Head-scratcher for sure.


One more thing, I tried using ImageMagick's "identify" on the example file from this discussion, and got the following output:

Image: alexa_anamorphic.jpg
Format: JPEG (Joint Photographic Experts Group JFIF format)
Mime type: image/jpeg
Class: DirectClass
Geometry: 2880x2160+0+0
Resolution: 2400x1200
Print size: 1.2x1.8
...

It doesn't give aspect ratio per se, but the "print size" makes it seem that ImageMagick agrees with me that this combination of image size and pixel "resolution" (density) implies an overall image that is thin and long!

Anybody want to check with other apps? So far, Nuke stands alone in interpreting resolution 2400x1200 to mean wide pixels, versus agreement among ImageMagick, OpenEXR, OIIO, and the apparent wording of the JFIF spec.

-- lg


On Jan 30, 2015, at 3:28 PM, Larry Gritz <***@larrygritz.com> wrote:

> 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 <***@gmail.com> 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 <***@gmail.com> 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
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[Nathan Rusch]

> 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

[Larry Gritz]

On Jan 30, 2015, at 4:38 PM, Nathan Rusch <***@gmail.com> 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
***@larrygritz.com

[ran sariel]

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<***@gmail.com> 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
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[haggi krey]

Hi,

I am reading image files with OIIO in my texure system.
Is it possible to use udim tiled textures from Mari, Mudbox or Zbrush
with OIIO?
And if yes, how? Do I have to implement the reading of the correct file
name by myself in my texture file osl shader or are there any helpful
procedures in OIIO?

haggi

[Larry Gritz]

(CC'ing osl-dev because the fun part of this is on the OSL side.)


On Feb 2, 2015, at 11:52 AM, haggi krey <***@haggi.de> wrote:

> I am reading image files with OIIO in my texure system.
> Is it possible to use udim tiled textures from Mari, Mudbox or Zbrush with OIIO?
> And if yes, how? Do I have to implement the reading of the correct file name by myself in my texture file osl shader or are there any helpful procedures in OIIO?


You need to generate the texture name based on the coordinates:

umap = int(s);
vmap = int(t);
udim = 1001 + 10*vmap + umap;
filename = format ("%s%04d.tx", basename, udim);

look up texture (filename, s-umap, t-vmap, ...)

or, if your v's are all upside down, then 1.0 - (t-vmap).

BUT... if you are using this from OSL (I'm presuming, because I see you on the mail list there frequently), the repeated calls to create strings on every shade will be a bottleneck. But there's a special trick to make it super fast and fully constant folded!


shader
udimtexture (string basename = "",
float s = 0 [[int lockgeom = 0]],
float t = 0 [[int lockgeom = 0]],
output color Cout = 0)
{
#define NAME(i) format("%s%d.tx",basename,i+1001)
#define TENNAMES(j) NAME(10*j+0),NAME(10*j+1),NAME(10*j+2),NAME(10*j+3),NAME(10*j+4), \
NAME(10*j+5),NAME(10*j+6),NAME(10*j+7),NAME(10*j+8),NAME(10*j+9)
#define TENROWS TENNAMES(0),TENNAMES(1),TENNAMES(2),TENNAMES(3),TENNAMES(4), \
TENNAMES(5),TENNAMES(6),TENNAMES(7),TENNAMES(8),TENNAMES(9)

string filenames[100] = { TENROWS };
// The magic here is that the 'format' calls, since their parameters in this
// macro expansion are all constant, will be constant-folded at runtime, and thus
// the entire filenames[] array will become just constant memory that is initialized
// just once, NOT every time the shader executes.
// NOTE: if you expect more than 10 rows in v, adjust the above as needed.

#undef NAME
#undef TENNAME
#undef TENROW

int umap = int(s);
int vmap = int(t);
int udim = 1001 + 10*vmap + umap;
string filename = filenames[udim]; // MAGIC! just an array lookup, no format calls
Cout = texture (filename, s-umap, 1.0 - (t-vmap));
}





--
Larry Gritz
***@larrygritz.com

[haggi krey]

Yes, indeed I'm using osl.
Thanks a lot for the great help - as always, I'll try it.

haggi

Am 02.02.2015 um 21:11 schrieb Larry Gritz:
> (CC'ing osl-dev because the fun part of this is on the OSL side.)
>
>
> On Feb 2, 2015, at 11:52 AM, haggi krey <***@haggi.de> wrote:
>
>> I am reading image files with OIIO in my texure system.
>> Is it possible to use udim tiled textures from Mari, Mudbox or Zbrush with OIIO?
>> And if yes, how? Do I have to implement the reading of the correct file name by myself in my texture file osl shader or are there any helpful procedures in OIIO?
>
> You need to generate the texture name based on the coordinates:
>
> umap = int(s);
> vmap = int(t);
> udim = 1001 + 10*vmap + umap;
> filename = format ("%s%04d.tx", basename, udim);
>
> look up texture (filename, s-umap, t-vmap, ...)
>
> or, if your v's are all upside down, then 1.0 - (t-vmap).
>
> BUT... if you are using this from OSL (I'm presuming, because I see you on the mail list there frequently), the repeated calls to create strings on every shade will be a bottleneck. But there's a special trick to make it super fast and fully constant folded!
>
>
> shader
> udimtexture (string basename = "",
> float s = 0 [[int lockgeom = 0]],
> float t = 0 [[int lockgeom = 0]],
> output color Cout = 0)
> {
> #define NAME(i) format("%s%d.tx",basename,i+1001)
> #define TENNAMES(j) NAME(10*j+0),NAME(10*j+1),NAME(10*j+2),NAME(10*j+3),NAME(10*j+4), \
> NAME(10*j+5),NAME(10*j+6),NAME(10*j+7),NAME(10*j+8),NAME(10*j+9)
> #define TENROWS TENNAMES(0),TENNAMES(1),TENNAMES(2),TENNAMES(3),TENNAMES(4), \
> TENNAMES(5),TENNAMES(6),TENNAMES(7),TENNAMES(8),TENNAMES(9)
>
> string filenames[100] = { TENROWS };
> // The magic here is that the 'format' calls, since their parameters in this
> // macro expansion are all constant, will be constant-folded at runtime, and thus
> // the entire filenames[] array will become just constant memory that is initialized
> // just once, NOT every time the shader executes.
> // NOTE: if you expect more than 10 rows in v, adjust the above as needed.
>
> #undef NAME
> #undef TENNAME
> #undef TENROW
>
> int umap = int(s);
> int vmap = int(t);
> int udim = 1001 + 10*vmap + umap;
> string filename = filenames[udim]; // MAGIC! just an array lookup, no format calls
> Cout = texture (filename, s-umap, 1.0 - (t-vmap));
> }
>
>
>
>
>
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
>

[haggi krey]

Just wanted to let you know that this procedure works really fine. I
extended it a bit to be able to use ZBrush/Mudbox style udims as well.
Thanks again.

Am Montag, 2. Februar 2015 21:11:19 UTC+1 schrieb Larry Gritz:
>
> (CC'ing osl-dev because the fun part of this is on the OSL side.)
>
>
> On Feb 2, 2015, at 11:52 AM, haggi krey <***@haggi.de <javascript:>>
> wrote:
>
> > I am reading image files with OIIO in my texure system.
> > Is it possible to use udim tiled textures from Mari, Mudbox or Zbrush
> with OIIO?
> > And if yes, how? Do I have to implement the reading of the correct file
> name by myself in my texture file osl shader or are there any helpful
> procedures in OIIO?
>
>
> You need to generate the texture name based on the coordinates:
>
> umap = int(s);
> vmap = int(t);
> udim = 1001 + 10*vmap + umap;
> filename = format ("%s%04d.tx", basename, udim);
>
> look up texture (filename, s-umap, t-vmap, ...)
>
> or, if your v's are all upside down, then 1.0 - (t-vmap).
>
> BUT... if you are using this from OSL (I'm presuming, because I see you on
> the mail list there frequently), the repeated calls to create strings on
> every shade will be a bottleneck. But there's a special trick to make it
> super fast and fully constant folded!
>
>
> shader
> udimtexture (string basename = "",
> float s = 0 [[int lockgeom = 0]],
> float t = 0 [[int lockgeom = 0]],
> output color Cout = 0)
> {
> #define NAME(i) format("%s%d.tx",basename,i+1001)
> #define TENNAMES(j)
> NAME(10*j+0),NAME(10*j+1),NAME(10*j+2),NAME(10*j+3),NAME(10*j+4), \
>
> NAME(10*j+5),NAME(10*j+6),NAME(10*j+7),NAME(10*j+8),NAME(10*j+9)
> #define TENROWS
> TENNAMES(0),TENNAMES(1),TENNAMES(2),TENNAMES(3),TENNAMES(4), \
>
> TENNAMES(5),TENNAMES(6),TENNAMES(7),TENNAMES(8),TENNAMES(9)
>
> string filenames[100] = { TENROWS };
> // The magic here is that the 'format' calls, since their parameters
> in this
> // macro expansion are all constant, will be constant-folded at
> runtime, and thus
> // the entire filenames[] array will become just constant memory that
> is initialized
> // just once, NOT every time the shader executes.
> // NOTE: if you expect more than 10 rows in v, adjust the above as
> needed.
>
> #undef NAME
> #undef TENNAME
> #undef TENROW
>
> int umap = int(s);
> int vmap = int(t);
> int udim = 1001 + 10*vmap + umap;
> string filename = filenames[udim]; // MAGIC! just an array lookup,
> no format calls
> Cout = texture (filename, s-umap, 1.0 - (t-vmap));
> }
>
>
>
>
>
> --
> Larry Gritz
> ***@larrygritz.com <javascript:>
>
>
>
>

[Larry Gritz]

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 <***@theembassyvfx.com> 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<***@gmail.com> 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
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[ran sariel]

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<***@theembassyvfx.com> 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<***@gmail.com> 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
>>> ***@larrygritz.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> 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: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

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 <***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@gmail.com> 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
>>>> ***@larrygritz.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> 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: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[ran sariel]

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<***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@gmail.com> 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
>>>>> ***@larrygritz.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> 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: [phone] ext. 244
>>>>
>>>> ***@theembassyvfx.com
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> --
>>> Larry Gritz
>>> ***@larrygritz.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> 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: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[ran sariel]

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<***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@gmail.com> 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
>>>>> ***@larrygritz.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> 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: [phone] ext. 244
>>>>
>>>> ***@theembassyvfx.com
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> --
>>> Larry Gritz
>>> ***@larrygritz.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> 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: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

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 <***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@gmail.com> 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
>>>>>> ***@larrygritz.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-***@lists.openimageio.org
>>>>>> 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: [phone] ext. 244
>>>>>
>>>>> ***@theembassyvfx.com
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> --
>>>> Larry Gritz
>>>> ***@larrygritz.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> 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: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[Ran Sariel]

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


On Wed, Feb 18, 2015 at 1:50 PM, Larry Gritz <***@larrygritz.com> 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 <***@theembassyvfx.com> 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<***@theembassyvfx.com>
> 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<***@theembassyvfx.com>
> 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<***@gmail.com>
> 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
> >>>>>> ***@larrygritz.com
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Oiio-dev mailing list
> >>>>>> Oiio-***@lists.openimageio.org
> >>>>>> 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: [phone] ext. 244
> >>>>>
> >>>>> ***@theembassyvfx.com
> >>>>>
> >>>>> _______________________________________________
> >>>>> Oiio-dev mailing list
> >>>>> Oiio-***@lists.openimageio.org
> >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> >>>> --
> >>>> Larry Gritz
> >>>> ***@larrygritz.com
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Oiio-dev mailing list
> >>>> Oiio-***@lists.openimageio.org
> >>>> 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: [phone] ext. 244
> >>>
> >>> ***@theembassyvfx.com
> >>>
> >>> _______________________________________________
> >>> Oiio-dev mailing list
> >>> Oiio-***@lists.openimageio.org
> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> >> --
> >> Larry Gritz
> >> ***@larrygritz.com
> >>
> >>
> >>
> >> _______________________________________________
> >> Oiio-dev mailing list
> >> Oiio-***@lists.openimageio.org
> >> 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: [phone] ext. 244
> >
> > ***@theembassyvfx.com
> >
> > _______________________________________________
> > Oiio-dev mailing list
> > Oiio-***@lists.openimageio.org
> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>

[Larry Gritz]

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 <***@theembassyvfx.com> wrote:

> current master.
> oiiotool in.exr -attrib "PixelAspectRatio" 0.5 -o nonsquare.jpg
>
>
> On Wed, Feb 18, 2015 at 1:50 PM, Larry Gritz <***@larrygritz.com> 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 <***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@gmail.com> 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
> >>>>>> ***@larrygritz.com
> >>>>>>
> >>>>>>
> >>>>>>
> >>>>>> _______________________________________________
> >>>>>> Oiio-dev mailing list
> >>>>>> Oiio-***@lists.openimageio.org
> >>>>>> 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: [phone] ext. 244
> >>>>>
> >>>>> ***@theembassyvfx.com
> >>>>>
> >>>>> _______________________________________________
> >>>>> Oiio-dev mailing list
> >>>>> Oiio-***@lists.openimageio.org
> >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> >>>> --
> >>>> Larry Gritz
> >>>> ***@larrygritz.com
> >>>>
> >>>>
> >>>>
> >>>> _______________________________________________
> >>>> Oiio-dev mailing list
> >>>> Oiio-***@lists.openimageio.org
> >>>> 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: [phone] ext. 244
> >>>
> >>> ***@theembassyvfx.com
> >>>
> >>> _______________________________________________
> >>> Oiio-dev mailing list
> >>> Oiio-***@lists.openimageio.org
> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> >> --
> >> Larry Gritz
> >> ***@larrygritz.com
> >>
> >>
> >>
> >> _______________________________________________
> >> Oiio-dev mailing list
> >> Oiio-***@lists.openimageio.org
> >> 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: [phone] ext. 244
> >
> > ***@theembassyvfx.com
> >
> > _______________________________________________
> > Oiio-dev mailing list
> > Oiio-***@lists.openimageio.org
> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[ran sariel]

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 <***@theembassyvfx.com
> <mailto:***@theembassyvfx.com>> wrote:
>
>> current master.
>> oiiotool in.exr -attrib "PixelAspectRatio" 0.5 -o nonsquare.jpg
>>
>>
>> On Wed, Feb 18, 2015 at 1:50 PM, Larry Gritz <***@larrygritz.com
>> <mailto:***@larrygritz.com>> 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
>> <***@theembassyvfx.com <mailto:***@theembassyvfx.com>> 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<***@theembassyvfx.com
>> <mailto:***@theembassyvfx.com>> 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<***@theembassyvfx.com
>> <mailto:***@theembassyvfx.com>> 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<***@gmail.com <mailto:***@gmail.com>> 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
>> >>>>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>> >>>>>>
>> >>>>>>
>> >>>>>>
>> >>>>>> _______________________________________________
>> >>>>>> Oiio-dev mailing list
>> >>>>>> Oiio-***@lists.openimageio.org
>> <mailto:Oiio-***@lists.openimageio.org>
>> >>>>>>
>> 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: [phone] ext. 244
>> <tel:%28604%29%20696-6862%20ext.%20244>
>> >>>>>
>> >>>>> ***@theembassyvfx.com <mailto:***@theembassyvfx.com>
>> >>>>>
>> >>>>> _______________________________________________
>> >>>>> Oiio-dev mailing list
>> >>>>> Oiio-***@lists.openimageio.org
>> <mailto:Oiio-***@lists.openimageio.org>
>> >>>>>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> >>>> --
>> >>>> Larry Gritz
>> >>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>> >>>>
>> >>>>
>> >>>>
>> >>>> _______________________________________________
>> >>>> Oiio-dev mailing list
>> >>>> Oiio-***@lists.openimageio.org
>> <mailto:Oiio-***@lists.openimageio.org>
>> >>>>
>> 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: [phone] ext. 244
>> <tel:%28604%29%20696-6862%20ext.%20244>
>> >>>
>> >>> ***@theembassyvfx.com <mailto:***@theembassyvfx.com>
>> >>>
>> >>> _______________________________________________
>> >>> Oiio-dev mailing list
>> >>> Oiio-***@lists.openimageio.org
>> <mailto:Oiio-***@lists.openimageio.org>
>> >>>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> >> --
>> >> Larry Gritz
>> >> ***@larrygritz.com <mailto:***@larrygritz.com>
>> >>
>> >>
>> >>
>> >> _______________________________________________
>> >> Oiio-dev mailing list
>> >> Oiio-***@lists.openimageio.org
>> <mailto:Oiio-***@lists.openimageio.org>
>> >> 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: [phone] ext. 244
>> <tel:%28604%29%20696-6862%20ext.%20244>
>> >
>> > ***@theembassyvfx.com <mailto:***@theembassyvfx.com>
>> >
>> > _______________________________________________
>> > Oiio-dev mailing list
>> > Oiio-***@lists.openimageio.org
>> <mailto:Oiio-***@lists.openimageio.org>
>> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>> --
>> Larry Gritz
>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> <mailto:Oiio-***@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org <mailto:Oiio-***@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> ***@larrygritz.com <mailto:***@larrygritz.com>
>
>
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

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 <***@theembassyvfx.com> 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 <***@theembassyvfx.com> wrote:
>>
>>> current master.
>>> oiiotool in.exr -attrib "PixelAspectRatio" 0.5 -o nonsquare.jpg
>>>
>>>
>>> On Wed, Feb 18, 2015 at 1:50 PM, Larry Gritz <***@larrygritz.com> 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 <***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@gmail.com> 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
>>> >>>>>> ***@larrygritz.com
>>> >>>>>>
>>> >>>>>>
>>> >>>>>>
>>> >>>>>> _______________________________________________
>>> >>>>>> Oiio-dev mailing list
>>> >>>>>> Oiio-***@lists.openimageio.org
>>> >>>>>> 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: [phone] ext. 244
>>> >>>>>
>>> >>>>> ***@theembassyvfx.com
>>> >>>>>
>>> >>>>> _______________________________________________
>>> >>>>> Oiio-dev mailing list
>>> >>>>> Oiio-***@lists.openimageio.org
>>> >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> >>>> --
>>> >>>> Larry Gritz
>>> >>>> ***@larrygritz.com
>>> >>>>
>>> >>>>
>>> >>>>
>>> >>>> _______________________________________________
>>> >>>> Oiio-dev mailing list
>>> >>>> Oiio-***@lists.openimageio.org
>>> >>>> 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: [phone] ext. 244
>>> >>>
>>> >>> ***@theembassyvfx.com
>>> >>>
>>> >>> _______________________________________________
>>> >>> Oiio-dev mailing list
>>> >>> Oiio-***@lists.openimageio.org
>>> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> >> --
>>> >> Larry Gritz
>>> >> ***@larrygritz.com
>>> >>
>>> >>
>>> >>
>>> >> _______________________________________________
>>> >> Oiio-dev mailing list
>>> >> Oiio-***@lists.openimageio.org
>>> >> 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: [phone] ext. 244
>>> >
>>> > ***@theembassyvfx.com
>>> >
>>> > _______________________________________________
>>> > Oiio-dev mailing list
>>> > Oiio-***@lists.openimageio.org
>>> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>> --
>>> Larry Gritz
>>> ***@larrygritz.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[ran sariel]

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 <***@theembassyvfx.com
> <mailto:***@theembassyvfx.com>> 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 <***@theembassyvfx.com
>>> <mailto:***@theembassyvfx.com>> wrote:
>>>
>>>> current master.
>>>> oiiotool in.exr -attrib "PixelAspectRatio" 0.5 -o nonsquare.jpg
>>>>
>>>>
>>>> On Wed, Feb 18, 2015 at 1:50 PM, Larry Gritz <***@larrygritz.com
>>>> <mailto:***@larrygritz.com>> 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
>>>> <***@theembassyvfx.com <mailto:***@theembassyvfx.com>>
>>>> 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<***@theembassyvfx.com
>>>> <mailto:***@theembassyvfx.com>> 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<***@theembassyvfx.com
>>>> <mailto:***@theembassyvfx.com>> 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<***@gmail.com <mailto:***@gmail.com>>
>>>> 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
>>>> >>>>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>>
>>>> >>>>>> _______________________________________________
>>>> >>>>>> Oiio-dev mailing list
>>>> >>>>>> Oiio-***@lists.openimageio.org
>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>> >>>>>>
>>>> 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: [phone] ext. 244
>>>> <tel:%28604%29%20696-6862%20ext.%20244>
>>>> >>>>>
>>>> >>>>> ***@theembassyvfx.com <mailto:***@theembassyvfx.com>
>>>> >>>>>
>>>> >>>>> _______________________________________________
>>>> >>>>> Oiio-dev mailing list
>>>> >>>>> Oiio-***@lists.openimageio.org
>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>> >>>>>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> >>>> --
>>>> >>>> Larry Gritz
>>>> >>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>> >>>>
>>>> >>>>
>>>> >>>>
>>>> >>>> _______________________________________________
>>>> >>>> Oiio-dev mailing list
>>>> >>>> Oiio-***@lists.openimageio.org
>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>> >>>>
>>>> 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: [phone] ext. 244
>>>> <tel:%28604%29%20696-6862%20ext.%20244>
>>>> >>>
>>>> >>> ***@theembassyvfx.com <mailto:***@theembassyvfx.com>
>>>> >>>
>>>> >>> _______________________________________________
>>>> >>> Oiio-dev mailing list
>>>> >>> Oiio-***@lists.openimageio.org
>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>> >>>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> >> --
>>>> >> Larry Gritz
>>>> >> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>> >>
>>>> >>
>>>> >>
>>>> >> _______________________________________________
>>>> >> Oiio-dev mailing list
>>>> >> Oiio-***@lists.openimageio.org
>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>> >>
>>>> 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: [phone] ext. 244
>>>> <tel:%28604%29%20696-6862%20ext.%20244>
>>>> >
>>>> > ***@theembassyvfx.com <mailto:***@theembassyvfx.com>
>>>> >
>>>> > _______________________________________________
>>>> > Oiio-dev mailing list
>>>> > Oiio-***@lists.openimageio.org
>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>> >
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>
>>>> --
>>>> Larry Gritz
>>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org <mailto:Oiio-***@lists.openimageio.org>
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>> --
>>> Larry Gritz
>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> 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: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org <mailto:Oiio-***@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> ***@larrygritz.com <mailto:***@larrygritz.com>
>
>
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

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 <***@theembassyvfx.com> 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 <***@theembassyvfx.com> 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 <***@theembassyvfx.com> wrote:
>>>>
>>>>> current master.
>>>>> oiiotool in.exr -attrib "PixelAspectRatio" 0.5 -o nonsquare.jpg
>>>>>
>>>>>
>>>>> On Wed, Feb 18, 2015 at 1:50 PM, Larry Gritz <***@larrygritz.com> 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 <***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@gmail.com> 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
>>>>> >>>>>> ***@larrygritz.com
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>>
>>>>> >>>>>> _______________________________________________
>>>>> >>>>>> Oiio-dev mailing list
>>>>> >>>>>> Oiio-***@lists.openimageio.org
>>>>> >>>>>> 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: [phone] ext. 244
>>>>> >>>>>
>>>>> >>>>> ***@theembassyvfx.com
>>>>> >>>>>
>>>>> >>>>> _______________________________________________
>>>>> >>>>> Oiio-dev mailing list
>>>>> >>>>> Oiio-***@lists.openimageio.org
>>>>> >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> >>>> --
>>>>> >>>> Larry Gritz
>>>>> >>>> ***@larrygritz.com
>>>>> >>>>
>>>>> >>>>
>>>>> >>>>
>>>>> >>>> _______________________________________________
>>>>> >>>> Oiio-dev mailing list
>>>>> >>>> Oiio-***@lists.openimageio.org
>>>>> >>>> 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: [phone] ext. 244
>>>>> >>>
>>>>> >>> ***@theembassyvfx.com
>>>>> >>>
>>>>> >>> _______________________________________________
>>>>> >>> Oiio-dev mailing list
>>>>> >>> Oiio-***@lists.openimageio.org
>>>>> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>> >> --
>>>>> >> Larry Gritz
>>>>> >> ***@larrygritz.com
>>>>> >>
>>>>> >>
>>>>> >>
>>>>> >> _______________________________________________
>>>>> >> Oiio-dev mailing list
>>>>> >> Oiio-***@lists.openimageio.org
>>>>> >> 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: [phone] ext. 244
>>>>> >
>>>>> > ***@theembassyvfx.com
>>>>> >
>>>>> > _______________________________________________
>>>>> > Oiio-dev mailing list
>>>>> > Oiio-***@lists.openimageio.org
>>>>> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>
>>>>> --
>>>>> Larry Gritz
>>>>> ***@larrygritz.com
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>
>>>> --
>>>> Larry Gritz
>>>> ***@larrygritz.com
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> 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: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[Larry Gritz]

Fix: https://github.com/OpenImageIO/oiio/pull/1066


On Feb 18, 2015, at 2:56 PM, Larry Gritz <***@larrygritz.com> 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 <***@theembassyvfx.com> 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 <***@theembassyvfx.com> 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 <***@theembassyvfx.com> wrote:
>>>>>
>>>>>> current master.
>>>>>> oiiotool in.exr -attrib "PixelAspectRatio" 0.5 -o nonsquare.jpg
>>>>>>
>>>>>>
>>>>>> On Wed, Feb 18, 2015 at 1:50 PM, Larry Gritz <***@larrygritz.com> 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 <***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@gmail.com> 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
>>>>>> >>>>>> ***@larrygritz.com
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>>
>>>>>> >>>>>> _______________________________________________
>>>>>> >>>>>> Oiio-dev mailing list
>>>>>> >>>>>> Oiio-***@lists.openimageio.org
>>>>>> >>>>>> 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: [phone] ext. 244
>>>>>> >>>>>
>>>>>> >>>>> ***@theembassyvfx.com
>>>>>> >>>>>
>>>>>> >>>>> _______________________________________________
>>>>>> >>>>> Oiio-dev mailing list
>>>>>> >>>>> Oiio-***@lists.openimageio.org
>>>>>> >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>> >>>> --
>>>>>> >>>> Larry Gritz
>>>>>> >>>> ***@larrygritz.com
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>>
>>>>>> >>>> _______________________________________________
>>>>>> >>>> Oiio-dev mailing list
>>>>>> >>>> Oiio-***@lists.openimageio.org
>>>>>> >>>> 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: [phone] ext. 244
>>>>>> >>>
>>>>>> >>> ***@theembassyvfx.com
>>>>>> >>>
>>>>>> >>> _______________________________________________
>>>>>> >>> Oiio-dev mailing list
>>>>>> >>> Oiio-***@lists.openimageio.org
>>>>>> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>> >> --
>>>>>> >> Larry Gritz
>>>>>> >> ***@larrygritz.com
>>>>>> >>
>>>>>> >>
>>>>>> >>
>>>>>> >> _______________________________________________
>>>>>> >> Oiio-dev mailing list
>>>>>> >> Oiio-***@lists.openimageio.org
>>>>>> >> 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: [phone] ext. 244
>>>>>> >
>>>>>> > ***@theembassyvfx.com
>>>>>> >
>>>>>> > _______________________________________________
>>>>>> > Oiio-dev mailing list
>>>>>> > Oiio-***@lists.openimageio.org
>>>>>> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>
>>>>>> --
>>>>>> Larry Gritz
>>>>>> ***@larrygritz.com
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-***@lists.openimageio.org
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-***@lists.openimageio.org
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>
>>>>> --
>>>>> Larry Gritz
>>>>> ***@larrygritz.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> 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: [phone] ext. 244
>>>>
>>>> ***@theembassyvfx.com
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>> --
>>> Larry Gritz
>>> ***@larrygritz.com
>>>
>>>
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> 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: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[ran sariel]

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 <***@larrygritz.com
> <mailto:***@larrygritz.com>> 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 <***@theembassyvfx.com
>> <mailto:***@theembassyvfx.com>> 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 <***@theembassyvfx.com
>>>> <mailto:***@theembassyvfx.com>> 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
>>>>>> <***@theembassyvfx.com <mailto:***@theembassyvfx.com>> wrote:
>>>>>>
>>>>>>> current master.
>>>>>>> oiiotool in.exr -attrib "PixelAspectRatio" 0.5 -o nonsquare.jpg
>>>>>>>
>>>>>>>
>>>>>>> On Wed, Feb 18, 2015 at 1:50 PM, Larry Gritz <***@larrygritz.com
>>>>>>> <mailto:***@larrygritz.com>> 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
>>>>>>> <***@theembassyvfx.com
>>>>>>> <mailto:***@theembassyvfx.com>> 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<***@theembassyvfx.com
>>>>>>> <mailto:***@theembassyvfx.com>> 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<***@theembassyvfx.com
>>>>>>> <mailto:***@theembassyvfx.com>> 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<***@gmail.com <mailto:***@gmail.com>>
>>>>>>> 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
>>>>>>> >>>>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>>>>> >>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>>
>>>>>>> >>>>>> _______________________________________________
>>>>>>> >>>>>> Oiio-dev mailing list
>>>>>>> >>>>>> Oiio-***@lists.openimageio.org
>>>>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>>>>> >>>>>>
>>>>>>> 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: [phone] ext. 244
>>>>>>> <tel:%28604%29%20696-6862%20ext.%20244>
>>>>>>> >>>>>
>>>>>>> >>>>> ***@theembassyvfx.com <mailto:***@theembassyvfx.com>
>>>>>>> >>>>>
>>>>>>> >>>>> _______________________________________________
>>>>>>> >>>>> Oiio-dev mailing list
>>>>>>> >>>>> Oiio-***@lists.openimageio.org
>>>>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>>>>> >>>>>
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>> >>>> --
>>>>>>> >>>> Larry Gritz
>>>>>>> >>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>>
>>>>>>> >>>> _______________________________________________
>>>>>>> >>>> Oiio-dev mailing list
>>>>>>> >>>> Oiio-***@lists.openimageio.org
>>>>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>>>>> >>>>
>>>>>>> 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: [phone] ext. 244
>>>>>>> <tel:%28604%29%20696-6862%20ext.%20244>
>>>>>>> >>>
>>>>>>> >>> ***@theembassyvfx.com <mailto:***@theembassyvfx.com>
>>>>>>> >>>
>>>>>>> >>> _______________________________________________
>>>>>>> >>> Oiio-dev mailing list
>>>>>>> >>> Oiio-***@lists.openimageio.org
>>>>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>>>>> >>>
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>> >> --
>>>>>>> >> Larry Gritz
>>>>>>> >> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >>
>>>>>>> >> _______________________________________________
>>>>>>> >> Oiio-dev mailing list
>>>>>>> >> Oiio-***@lists.openimageio.org
>>>>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>>>>> >>
>>>>>>> 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: [phone] ext. 244
>>>>>>> <tel:%28604%29%20696-6862%20ext.%20244>
>>>>>>> >
>>>>>>> > ***@theembassyvfx.com <mailto:***@theembassyvfx.com>
>>>>>>> >
>>>>>>> > _______________________________________________
>>>>>>> > Oiio-dev mailing list
>>>>>>> > Oiio-***@lists.openimageio.org
>>>>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>>>>> >
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>
>>>>>>> --
>>>>>>> Larry Gritz
>>>>>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> Oiio-***@lists.openimageio.org
>>>>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> Oiio-***@lists.openimageio.org
>>>>>>> <mailto:Oiio-***@lists.openimageio.org>
>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>
>>>>>> --
>>>>>> Larry Gritz
>>>>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-***@lists.openimageio.org
>>>>>> 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: [phone] ext. 244
>>>>>
>>>>> ***@theembassyvfx.com
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org <mailto:Oiio-***@lists.openimageio.org>
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>
>>>> --
>>>> Larry Gritz
>>>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> 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: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org <mailto:Oiio-***@lists.openimageio.org>
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>> --
>> Larry Gritz
>> ***@larrygritz.com <mailto:***@larrygritz.com>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org <mailto:Oiio-***@lists.openimageio.org>
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>
> --
> Larry Gritz
> ***@larrygritz.com <mailto:***@larrygritz.com>
>
>
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

OK, pushed to master and RB-1.5.


On Feb 18, 2015, at 3:57 PM, ran sariel <***@theembassyvfx.com> wrote:

> 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 <***@larrygritz.com> 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 <***@theembassyvfx.com> 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 <***@theembassyvfx.com> 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 <***@theembassyvfx.com> wrote:
>>>>>>>
>>>>>>>> current master.
>>>>>>>> oiiotool in.exr -attrib "PixelAspectRatio" 0.5 -o nonsquare.jpg
>>>>>>>>
>>>>>>>>
>>>>>>>> On Wed, Feb 18, 2015 at 1:50 PM, Larry Gritz <***@larrygritz.com> 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 <***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@theembassyvfx.com> 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<***@gmail.com> 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
>>>>>>>> >>>>>> ***@larrygritz.com
>>>>>>>> >>>>>>
>>>>>>>> >>>>>>
>>>>>>>> >>>>>>
>>>>>>>> >>>>>> _______________________________________________
>>>>>>>> >>>>>> Oiio-dev mailing list
>>>>>>>> >>>>>> Oiio-***@lists.openimageio.org
>>>>>>>> >>>>>> 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: [phone] ext. 244
>>>>>>>> >>>>>
>>>>>>>> >>>>> ***@theembassyvfx.com
>>>>>>>> >>>>>
>>>>>>>> >>>>> _______________________________________________
>>>>>>>> >>>>> Oiio-dev mailing list
>>>>>>>> >>>>> Oiio-***@lists.openimageio.org
>>>>>>>> >>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>> >>>> --
>>>>>>>> >>>> Larry Gritz
>>>>>>>> >>>> ***@larrygritz.com
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>>
>>>>>>>> >>>> _______________________________________________
>>>>>>>> >>>> Oiio-dev mailing list
>>>>>>>> >>>> Oiio-***@lists.openimageio.org
>>>>>>>> >>>> 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: [phone] ext. 244
>>>>>>>> >>>
>>>>>>>> >>> ***@theembassyvfx.com
>>>>>>>> >>>
>>>>>>>> >>> _______________________________________________
>>>>>>>> >>> Oiio-dev mailing list
>>>>>>>> >>> Oiio-***@lists.openimageio.org
>>>>>>>> >>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>> >> --
>>>>>>>> >> Larry Gritz
>>>>>>>> >> ***@larrygritz.com
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >>
>>>>>>>> >> _______________________________________________
>>>>>>>> >> Oiio-dev mailing list
>>>>>>>> >> Oiio-***@lists.openimageio.org
>>>>>>>> >> 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: [phone] ext. 244
>>>>>>>> >
>>>>>>>> > ***@theembassyvfx.com
>>>>>>>> >
>>>>>>>> > _______________________________________________
>>>>>>>> > Oiio-dev mailing list
>>>>>>>> > Oiio-***@lists.openimageio.org
>>>>>>>> > http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>>
>>>>>>>> --
>>>>>>>> Larry Gritz
>>>>>>>> ***@larrygritz.com
>>>>>>>>
>>>>>>>>
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> Oiio-***@lists.openimageio.org
>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>>
>>>>>>>> _______________________________________________
>>>>>>>> Oiio-dev mailing list
>>>>>>>> Oiio-***@lists.openimageio.org
>>>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>>>
>>>>>>> --
>>>>>>> Larry Gritz
>>>>>>> ***@larrygritz.com
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>>
>>>>>>> _______________________________________________
>>>>>>> Oiio-dev mailing list
>>>>>>> Oiio-***@lists.openimageio.org
>>>>>>> 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: [phone] ext. 244
>>>>>>
>>>>>> ***@theembassyvfx.com
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-***@lists.openimageio.org
>>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>>>
>>>>> --
>>>>> Larry Gritz
>>>>> ***@larrygritz.com
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> 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: [phone] ext. 244
>>>>
>>>> ***@theembassyvfx.com
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>
>>> --
>>> Larry Gritz
>>> ***@larrygritz.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[Nathan Rusch]

I just learned that JPEG may have its own separate (i.e. non-EXIF) tags for
XDensity and YDensity, and that is may also have its own "resolution units"
tag whose value is "dots per <linear unit>", all of which would certainly
create an interesting conflict.

Are these the values OIIO is currently looking at?

-Nathan

[Larry Gritz]

This is what was confusing my terminology!

In implementing the recent patch, I found that libjpeg was not reliable to set the xDensity and yDensity and that in JPEG files I found in the wild, they did not match anyway and the Exif ones tended to be sensible. So in OIIO, I am relying on the Exif fields. In theory, these should be the same thing, but in practice it looks like other apps I checked all honor the Exif, if found, rather than what's found in the base JPEG header fields.


On Jan 30, 2015, at 11:55 AM, Nathan Rusch <***@gmail.com> wrote:

> I just learned that JPEG may have its own separate (i.e. non-EXIF) tags for XDensity and YDensity, and that is may also have its own "resolution units" tag whose value is "dots per <linear unit>", all of which would certainly create an interesting conflict.
>
> Are these the values OIIO is currently looking at?
>
> -Nathan
>

--
Larry Gritz
***@larrygritz.com

[Larry Gritz]

Rule of thumb for future designers of image formats:

If your file contains Exif or XMP data, *DO NOT* have separate header fields redundantly holding data that could/should be in the Exif or XMP. That's just an invitation for them to contradict each other and cause chaos.



On Jan 30, 2015, at 11:58 AM, Larry Gritz <***@larrygritz.com> wrote:

> This is what was confusing my terminology!
>
> In implementing the recent patch, I found that libjpeg was not reliable to set the xDensity and yDensity and that in JPEG files I found in the wild, they did not match anyway and the Exif ones tended to be sensible. So in OIIO, I am relying on the Exif fields. In theory, these should be the same thing, but in practice it looks like other apps I checked all honor the Exif, if found, rather than what's found in the base JPEG header fields.
>
>
> On Jan 30, 2015, at 11:55 AM, Nathan Rusch <***@gmail.com> wrote:
>
>> I just learned that JPEG may have its own separate (i.e. non-EXIF) tags for XDensity and YDensity, and that is may also have its own "resolution units" tag whose value is "dots per <linear unit>", all of which would certainly create an interesting conflict.
>>
>> Are these the values OIIO is currently looking at?
>>
>> -Nathan
>>
>
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com

[ran sariel]

please find attached



On 01/30/2015 11:17 AM, Larry Gritz 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").
>
> 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.
>
> Can you send me (via private email is fine) one of those images that comes from Nuke so I can inspect exactly what's going on?
>
> Just to clarify again, there is no such thing as "PixelAspectRatio" metadata in a JPEG file (whereas there is in OpenEXR, for example). It just doesn't exist as such, in JPEG files. The pixel aspect is implied by the x and y density values. OIIO tries to shield you from this, computing the ratio and reporting it as PixelAspectRatio, and also if you give it a PixelAspectRatio, it will make sure to output densities that give the right ratio.
>
> -- lg
>
>
> On Jan 30, 2015, at 10:34 AM, ran sariel<***@theembassyvfx.com> wrote:
>
>> Hi Larry
>>
>> yes with PixelAspectRatio of 2 a square image will look twice as wide,
>> The individual pixesl are wider than they are tall.
>>
>>
>> On 01/29/2015 11:16 PM, Larry Gritz wrote:
>>> Sorry for the delay, I was tied up ALL day today.
>>>
>>> I'm still not clear on the basics of the situation.
>>>
>>> Is the image supposed to look wider than it is tall?
>>>
>>> Are the individual pixels in the image supposed to be wider than they are tall?
>>>
>>>
>>>
>>> On Jan 29, 2015, at 10:56 AM, ran sariel<***@theembassyvfx.com> wrote:
>>>
>>>> actually in this case, the resize is not changing the result,
>>>> running the conversion without the resize on the input image (exr with pixelAspectRatio 2 - according to both RV and oiiotool.)
>>>> I get a jpeg image that is not recognized by RV as having PixelAspectRatio of 2.
>>>> oiiotool recognizes that the image has a PixelAspectRatio attribute with a value of 2.
>>>> I guess other packages are expecting something different than that attribute, RV shows the density as 2400x1200 for the file written from nuke. and as 1 for the file converted by oiiotool.
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>>
>>>> On 01/29/2015 09:58 AM, Nathan Rusch wrote:
>>>>> Sorry, the old Ctrl + Enter hotkey got me again...
>>>>>
>>>>> I think an important thing here is to look at the command that was being run:
>>>>>
>>>>> oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio 2.0 -o nonsquare.jpg
>>>>>
>>>>> There is no non-uniform scaling being applied, and changing the pixel aspect ratio of the image should not change its physical resolution at all. As such, the result of this should be an image that, when viewed with proper pixel aspect ratio correction, should appear to be twice as wide as the original.
>>>>>
>>>>> Now, about those metadata tags...
>>>>>
>>>>> If you look at the EXIF tag definitions for XResolution and YResolution, the language is a bit strange:
>>>>>
>>>>> The number of pixels per<ResolutionUnit> in the<ImageWidth> direction. [...]
>>>>>
>>>>> If you reorient your thinking so the "resolution" of the image is actually whatever<ResolutionUnit> is (defaults to inches), it starts to make some sense. For a 512x512 square image at 72 dpi, the "resolution" is actually 7.111111 x 7.1111111.
>>>>>
>>>>> Now, if the<XResolution> and<YResolution> values of that same image are 2400 and 1200, respectively, and we take the language of the EXIF tags as-is, those 7.111111 inches of resolution are not going to be uniformly mapped to screen pixels in both dimensions(remember, "pixels per<ResolutionUnit>"). Instead, the result will be a "pixel image" twice as wide as it is tall.
>>>>>
>>>>> In practice, the resolution tags are treated as a ratio, and the image's pixel resolution is read directly from the file.
>>>>>
>>>>> Finally, even if you disagree with all of this (which I wouldn't really fault you for), the fact is that Nuke, RV, and Adobe products currently all agree on how they should be handled, so I think it might be best to try and stay consistent.
>>>>>
>>>>>
>>>>> -Nathan
>>>>>
>>>>>
>>>>>
>>>>> -----Original Message----- From: Larry Gritz
>>>>> Sent: Wednesday, January 28, 2015 11:04 PM
>>>>> To: OpenImageIO developers
>>>>> Subject: Re: [Oiio-dev] aspect ratio from oiiotool
>>>>>
>>>>> (WARNING: this whole explanation depends on your viewing with a fixed-width font.)
>>>>>
>>>>> I think maybe this is a disagreement between the different apps on what aspect ratio means.
>>>>>
>>>>> I very well could have screwed this up, so let me explain my thinking, and people can tell me if it makes sense or if I botched it.
>>>>>
>>>>> First of all, when we talk about the FRAME aspect ratio of a whole film image, we say the aspect is 1.85, or 16/9, or 2.35, or whatever, all of which are varying degrees of wider than they are tall. "Wider than tall" means a frame aspect ratio of greater than 1.0, "taller than wide" means a frame aspect ratio of less than 1.0. Right? So I'm gonna assume that the same is true of pixel aspect ratio.
>>>>>
>>>>> OK, here's my cartoon of a 2x2 image with square pixels. Let's make up some densities, say the image is supposed to print 1 cm wide and 1 cm tall, so XResolution = 2, YResolution = 2, ResolutionUnit = "cm".
>>>>>
>>>>> +---+---+ ^
>>>>> | * | * | |
>>>>> +---+---+ 1cm
>>>>> | * | * | |
>>>>> +---+---+ v
>>>>>
>>>>> <- 1cm ->
>>>>>
>>>>> We agree that this is a 1.0 aspect ratio, I assume. (I do hope you're viewing with a fixed width font)
>>>>>
>>>>> So let's say we want to cut the density in half horizontally, giving us wide pixels.
>>>>>
>>>>> +-------+ ^
>>>>> | * | |
>>>>> +-------+ 1cm
>>>>> | * | |
>>>>> +-------+ v
>>>>>
>>>>> <- 1cm ->
>>>>>
>>>>> There are still 2 vertical samples per cm, but only 1 horizontal sample per pixel. In other words, XResolution = 1, YResolution = 2.
>>>>>
>>>>> What is the PixelAspectRatio?
>>>>>
>>>>> Here's the shape of just one pixel:
>>>>>
>>>>> +-------+
>>>>> | |
>>>>> +-------+
>>>>>
>>>>> Remembering what we said about the aspect ratio of a whole frame, I would argue that the aspect ratio of a pixel that is wider than it is tall also should be a number greater than 1. For the above pixel, its PixelAspectRatio is 2.0, i.e. YResolution/XResolution. Also known as ydensity/xdensity, because note that in this terminology, "resolution" means "dots per length", like printer's resolution, NOT the faux "resolution" we use to describe the number of pixels in a whole image.
>>>>>
>>>>> Nuke wrote an image that it says is 1047x858, with 2400 horizontal pixels per inch (let's say; the units are undefined), so the image is 0.43625 inches wide, and at a y density of 1200 pixels per inch, it should be 0.715 inches tall:
>>>>>
>>>>> <-0.436"->
>>>>> ^ +--------+
>>>>> | | |
>>>>> | | |
>>>>> 0.715"| |
>>>>> | | |
>>>>> | | |
>>>>> | | |
>>>>> | | |
>>>>> v +--------+
>>>>>
>>>>> Is that what you expect? It's a tall skinny image?
>>>>>
>>>>> Or, do you expect a wide image? If you expect wide, then I'm going to go out on a limb and claim that Nuke is totally botching the meaning of the density fields, and thus the aspect ratio. Maybe rv is also getting it backwards, either coincidentally having made the same mistake, or else purposely backwards in order to match Nuke's broken output.
>>>>>
>>>>> Somebody let me know if I'm totally borked in my thinking about this. Maybe I'm the one who got it all wrong.
>>>>>
>>>>> -- lg
>>>>>
>>>>> PS. https://www.youtube.com/watch?v=Bt9zSfinwFA
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> 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: [phone] ext. 244
>>>>
>>>> ***@theembassyvfx.com
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>> --
>>> Larry Gritz
>>> ***@larrygritz.com
>>>
>>>
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> 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: [phone] ext. 244
>>
>> ***@theembassyvfx.com
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
> --
> Larry Gritz
> ***@larrygritz.com
>
>
>
> _______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> 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: [phone] ext. 244

***@theembassyvfx.com

[Larry Gritz]

I'm assuming that the frame should appear much wider than it is tall, the individual pixels should be wider than tall, and that the grey checks in the image should look square if the image is drawn properly?

Both OIIO and OSX's Preview.app report XResolution=2400 and YResolution=1200.

If the resolution fields are defined as "pixels per inch (or cm or unknown unit)", then how is this correct? Higher X resolution than Y means that the pixels are crammed more tightly together in the x direction than in the y direction, and thus the pixels should appear tall and skinny, not short and wide.

If I don't understand this properly, please ELI5.


On Jan 30, 2015, at 12:34 PM, ran sariel <***@theembassyvfx.com> wrote:

> please find attached
>
>
>
> On 01/30/2015 11:17 AM, Larry Gritz 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").
>>
>> 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.
>>
>> Can you send me (via private email is fine) one of those images that comes from Nuke so I can inspect exactly what's going on?
>>
>> Just to clarify again, there is no such thing as "PixelAspectRatio" metadata in a JPEG file (whereas there is in OpenEXR, for example). It just doesn't exist as such, in JPEG files. The pixel aspect is implied by the x and y density values. OIIO tries to shield you from this, computing the ratio and reporting it as PixelAspectRatio, and also if you give it a PixelAspectRatio, it will make sure to output densities that give the right ratio.
>>
>> -- lg
>>
>>
>> On Jan 30, 2015, at 10:34 AM, ran sariel<***@theembassyvfx.com> wrote:
>>
>>> Hi Larry
>>>
>>> yes with PixelAspectRatio of 2 a square image will look twice as wide,
>>> The individual pixesl are wider than they are tall.
>>>
>>>
>>> On 01/29/2015 11:16 PM, Larry Gritz wrote:
>>>> Sorry for the delay, I was tied up ALL day today.
>>>>
>>>> I'm still not clear on the basics of the situation.
>>>>
>>>> Is the image supposed to look wider than it is tall?
>>>>
>>>> Are the individual pixels in the image supposed to be wider than they are tall?
>>>>
>>>>
>>>>
>>>> On Jan 29, 2015, at 10:56 AM, ran sariel<***@theembassyvfx.com> wrote:
>>>>
>>>>> actually in this case, the resize is not changing the result,
>>>>> running the conversion without the resize on the input image (exr with pixelAspectRatio 2 - according to both RV and oiiotool.)
>>>>> I get a jpeg image that is not recognized by RV as having PixelAspectRatio of 2.
>>>>> oiiotool recognizes that the image has a PixelAspectRatio attribute with a value of 2.
>>>>> I guess other packages are expecting something different than that attribute, RV shows the density as 2400x1200 for the file written from nuke. and as 1 for the file converted by oiiotool.
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>>
>>>>> On 01/29/2015 09:58 AM, Nathan Rusch wrote:
>>>>>> Sorry, the old Ctrl + Enter hotkey got me again...
>>>>>>
>>>>>> I think an important thing here is to look at the command that was being run:
>>>>>>
>>>>>> oiiotool in.exr --ch R,G,B --resize 50% --attrib PixelAspectRatio 2.0 -o nonsquare.jpg
>>>>>>
>>>>>> There is no non-uniform scaling being applied, and changing the pixel aspect ratio of the image should not change its physical resolution at all. As such, the result of this should be an image that, when viewed with proper pixel aspect ratio correction, should appear to be twice as wide as the original.
>>>>>>
>>>>>> Now, about those metadata tags...
>>>>>>
>>>>>> If you look at the EXIF tag definitions for XResolution and YResolution, the language is a bit strange:
>>>>>>
>>>>>> The number of pixels per<ResolutionUnit> in the<ImageWidth> direction. [...]
>>>>>>
>>>>>> If you reorient your thinking so the "resolution" of the image is actually whatever<ResolutionUnit> is (defaults to inches), it starts to make some sense. For a 512x512 square image at 72 dpi, the "resolution" is actually 7.111111 x 7.1111111.
>>>>>>
>>>>>> Now, if the<XResolution> and<YResolution> values of that same image are 2400 and 1200, respectively, and we take the language of the EXIF tags as-is, those 7.111111 inches of resolution are not going to be uniformly mapped to screen pixels in both dimensions(remember, "pixels per<ResolutionUnit>"). Instead, the result will be a "pixel image" twice as wide as it is tall.
>>>>>>
>>>>>> In practice, the resolution tags are treated as a ratio, and the image's pixel resolution is read directly from the file.
>>>>>>
>>>>>> Finally, even if you disagree with all of this (which I wouldn't really fault you for), the fact is that Nuke, RV, and Adobe products currently all agree on how they should be handled, so I think it might be best to try and stay consistent.
>>>>>>
>>>>>>
>>>>>> -Nathan
>>>>>>
>>>>>>
>>>>>>
>>>>>> -----Original Message----- From: Larry Gritz
>>>>>> Sent: Wednesday, January 28, 2015 11:04 PM
>>>>>> To: OpenImageIO developers
>>>>>> Subject: Re: [Oiio-dev] aspect ratio from oiiotool
>>>>>>
>>>>>> (WARNING: this whole explanation depends on your viewing with a fixed-width font.)
>>>>>>
>>>>>> I think maybe this is a disagreement between the different apps on what aspect ratio means.
>>>>>>
>>>>>> I very well could have screwed this up, so let me explain my thinking, and people can tell me if it makes sense or if I botched it.
>>>>>>
>>>>>> First of all, when we talk about the FRAME aspect ratio of a whole film image, we say the aspect is 1.85, or 16/9, or 2.35, or whatever, all of which are varying degrees of wider than they are tall. "Wider than tall" means a frame aspect ratio of greater than 1.0, "taller than wide" means a frame aspect ratio of less than 1.0. Right? So I'm gonna assume that the same is true of pixel aspect ratio.
>>>>>>
>>>>>> OK, here's my cartoon of a 2x2 image with square pixels. Let's make up some densities, say the image is supposed to print 1 cm wide and 1 cm tall, so XResolution = 2, YResolution = 2, ResolutionUnit = "cm".
>>>>>>
>>>>>> +---+---+ ^
>>>>>> | * | * | |
>>>>>> +---+---+ 1cm
>>>>>> | * | * | |
>>>>>> +---+---+ v
>>>>>>
>>>>>> <- 1cm ->
>>>>>>
>>>>>> We agree that this is a 1.0 aspect ratio, I assume. (I do hope you're viewing with a fixed width font)
>>>>>>
>>>>>> So let's say we want to cut the density in half horizontally, giving us wide pixels.
>>>>>>
>>>>>> +-------+ ^
>>>>>> | * | |
>>>>>> +-------+ 1cm
>>>>>> | * | |
>>>>>> +-------+ v
>>>>>>
>>>>>> <- 1cm ->
>>>>>>
>>>>>> There are still 2 vertical samples per cm, but only 1 horizontal sample per pixel. In other words, XResolution = 1, YResolution = 2.
>>>>>>
>>>>>> What is the PixelAspectRatio?
>>>>>>
>>>>>> Here's the shape of just one pixel:
>>>>>>
>>>>>> +-------+
>>>>>> | |
>>>>>> +-------+
>>>>>>
>>>>>> Remembering what we said about the aspect ratio of a whole frame, I would argue that the aspect ratio of a pixel that is wider than it is tall also should be a number greater than 1. For the above pixel, its PixelAspectRatio is 2.0, i.e. YResolution/XResolution. Also known as ydensity/xdensity, because note that in this terminology, "resolution" means "dots per length", like printer's resolution, NOT the faux "resolution" we use to describe the number of pixels in a whole image.
>>>>>>
>>>>>> Nuke wrote an image that it says is 1047x858, with 2400 horizontal pixels per inch (let's say; the units are undefined), so the image is 0.43625 inches wide, and at a y density of 1200 pixels per inch, it should be 0.715 inches tall:
>>>>>>
>>>>>> <-0.436"->
>>>>>> ^ +--------+
>>>>>> | | |
>>>>>> | | |
>>>>>> 0.715"| |
>>>>>> | | |
>>>>>> | | |
>>>>>> | | |
>>>>>> | | |
>>>>>> v +--------+
>>>>>>
>>>>>> Is that what you expect? It's a tall skinny image?
>>>>>>
>>>>>> Or, do you expect a wide image? If you expect wide, then I'm going to go out on a limb and claim that Nuke is totally botching the meaning of the density fields, and thus the aspect ratio. Maybe rv is also getting it backwards, either coincidentally having made the same mistake, or else purposely backwards in order to match Nuke's broken output.
>>>>>>
>>>>>> Somebody let me know if I'm totally borked in my thinking about this. Maybe I'm the one who got it all wrong.
>>>>>>
>>>>>> -- lg
>>>>>>
>>>>>> PS. https://www.youtube.com/watch?v=Bt9zSfinwFA
>>>>>>
>>>>>> _______________________________________________
>>>>>> Oiio-dev mailing list
>>>>>> Oiio-***@lists.openimageio.org
>>>>>> 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: [phone] ext. 244
>>>>>
>>>>> ***@theembassyvfx.com
>>>>>
>>>>> _______________________________________________
>>>>> Oiio-dev mailing list
>>>>> Oiio-***@lists.openimageio.org
>>>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>>>> --
>>>> Larry Gritz
>>>> ***@larrygritz.com
>>>>
>>>>
>>>>
>>>> _______________________________________________
>>>> Oiio-dev mailing list
>>>> Oiio-***@lists.openimageio.org
>>>> 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: [phone] ext. 244
>>>
>>> ***@theembassyvfx.com
>>>
>>> _______________________________________________
>>> Oiio-dev mailing list
>>> Oiio-***@lists.openimageio.org
>>> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org
>> --
>> Larry Gritz
>> ***@larrygritz.com
>>
>>
>>
>> _______________________________________________
>> Oiio-dev mailing list
>> Oiio-***@lists.openimageio.org
>> 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: [phone] ext. 244
>
> ***@theembassyvfx.com
>
> <alexa_anamorphic.jpg>_______________________________________________
> Oiio-dev mailing list
> Oiio-***@lists.openimageio.org
> http://lists.openimageio.org/listinfo.cgi/oiio-dev-openimageio.org

--
Larry Gritz
***@larrygritz.com