DPX Pixel Aspect Ratio

Started by imbenzenker, August 06, 2021, 07:01:53 PM

Previous topic - Next topic

imbenzenker

It would appear to me that metadata extracted from DPX (https://exiftool.org/TagNames/DPX.html) does not include Pixel Aspect Ratio.

Can this be added to ExifTool?

I am seeing it defined in the following file header spec websites (1 & 2 below).

I've created an image for you to test with, as well. I confirmed that it reports "sample_aspect_ratio": "2:1" when reading the file with ffprobe. This file will only be available for 7 days. Please let me know if you'd like the image by a different means of transfer.

DPX Image File: https://www.filemail.com/d/eijqrnxpehzirkf

1. https://web.archive.org/web/20180127215820/http://www.cineon.com/ff_draft.php#:~:text=U32%20%20%20pixel_aspect%5B2%5D%3B%20%20%20%20%20%20%20%20/*%20pixel%20aspect%20ratio%20(H%3AV)%20*/
2. https://www.fileformat.info/format/dpx/egff.htm#:~:text=DWORD%20%20AspectRatio%5B2%5D%3B%20%20%20%20%20%20/*%20Pixel%20aspect%20ratio%20(H%3AV)%20*/

Phil Harvey

Sorry, I'm finally getting around to this but your download link has expired for the DPX sample you prepared.  Could you re-upload it or attach it here?  Thanks.

Also, I have two other DPX samples at hand here, and they both give this when I add this feature to ExifTool:

Aspect Ratio                    : 4294967295 4294967295

which is probably why I am not decoding this.  What do you think this means?

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Hank


Phil Harvey

Often, a value of 4294967295 (0xffff) indicates an invalid or not-applicable value.  It would be odd if they used this for 1:1 because storing "1 1" makes so much more sense.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

Hank

It's been forever since I've programmed C++ for Windows, but the documentation used dword, which is a 32-bit value.
4,294,967,295 is one of those magical numbers, which to me equates with max value, not set, padding, or default value.
A little higher up in the documentation is the answer I think:
QuoteFile Details
The five DPX headers are all fixed in size and contain fields ranging in length from one to several hundred bytes. Fields of the SINGLE (16-bit) and DOUBLE (32-bit) floating-point data types are also common.
Any integer or real header fields that contain undefined data are to be initialized to their "all ones" value. In C, this is most easily accomplished by assigning the one's-complement of 0 to an undefined field, as follows:
WORD val = ~0;    /* Set val to 0xFFFF */
Undefined ASCII fields are initialized to all NULL (ASCII 00h) characters.

So they are performing a bitwise not operation on zero, hence 0xFFFFFFFF value

Don't know if the logic would dictate using XOriginalSize / YOriginalSize for aspect ratio if the AspectRatio metadata field is not set, and I tend to believe assumptions are dangerous.

Phil Harvey

So it does indicate an undefined value.  Not 1:1
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

imbenzenker

I believe I might have sent you down the wrong path as well. I'm not sure that pixel_aspect[2] is actually written into the file, but instead, it's written as


Field # Offset Length Type Content
1.43 972 4 R32 X input device pitch (samples/mm) (X determined by image orientation)
1.44 976 4 R32 Y input device pitch (samples/mm) (Y determined by image orientation)


And notice that those values are actually defined as R32 instead of U32, which shouldn't be much different other than the human interpretation of that data, and of course, the default value:


R32 32 bit real number (7F800000 hex (+ infinity))


I had not originally realized that 4294967295 was the 32-bit max value, so I was planning to ask you for your images to see if there was some sort of math that could have created those numbers based on the whole "samples / mm" bit discussed above.

Here is my original test image, not sure why I didn't think of using Google Drive previously:
https://drive.google.com/file/d/1YYgVmU7j1w7MfHq4GT0NT3kCUJrOXnHa/view?usp=sharing

Phil Harvey

The "input device pitch" tags are part of the Cineon File Format Version 4.5 format, which isn't what we have here.  The Cineon File Format Version 4.5 file begins with a magic number of 0x802A5FD7, which isn't what we have.  Your file starts with 53 44 50 58 ("SPDX").

The pixel_aspect value in your sample file is "0 0", so this isn't where the information is stored.

Could you prepare 2 identical samples, with the only difference being the aspect ratio?  This should make it easy to find where it is stored.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

imbenzenker

Gotcha.

I recreated the original sample to guarantee that I was creating the same image with just the Pixel Aspect Ratio being different. I also confirmed the existence of something (not sure if metadata or what) using ffprobe


ffprobe -loglevel panic -hide_banner -show_streams -select_streams v -print_format json testing.00007.dpx | grep sample_aspect_ratio
"sample_aspect_ratio": "2:1",

ffprobe -loglevel panic -hide_banner -show_streams -select_streams v -print_format json testing.00008.dpx | grep sample_aspect_ratio
"sample_aspect_ratio": "1:1",


I hope this helps


  • testing.00007.dpx
    https://drive.google.com/file/d/1KJlnhc1YX3mjItx7YI3HR24ES4gr_S1a/view?usp=sharing

  • testing.00008.dpx
    https://drive.google.com/file/d/1PGEvSk4xzsKIp6wupmLdU1KxMZ2wpuxK/view?usp=sharing

Phil Harvey

Ah, found it!  Thanks.

Somehow it was at offset 1628 in the file, but I was expecting AspectRatio at 1620.  I'll have to figure out why I was wrong.  But I can decode this in the next release.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).

imbenzenker

Thanks, Phil! Much appreciated.

Looking forward to it  :D

Phil Harvey

It seems to have been a simple error in my offset calculation for this tag only (it was commented out and not previously extracted), which was the source of much confusion.

ExifTool 12.31 (when released) will return this:

> exiftool ~/Desktop/ -ext DPX -aspectratio
======== /Users/phil/Desktop/testing.00008.dpx
Aspect Ratio                    : 1:1
======== /Users/phil/Desktop/testing.00007.dpx
Aspect Ratio                    : 2:1
    1 directories scanned
    2 image files read
> exiftool ~/Desktop/ -ext DPX -aspectratio#
======== /Users/phil/Desktop/testing.00008.dpx
Aspect Ratio                    : 1200 1200
======== /Users/phil/Desktop/testing.00007.dpx
Aspect Ratio                    : 2400 1200
    1 directories scanned
    2 image files read


Thanks for your patience with this.

- Phil
...where DIR is the name of a directory/folder containing the images.  On Mac/Linux/PowerShell, use single quotes (') instead of double quotes (") around arguments containing a dollar sign ($).