Running Flame 2022_0_1 on Linux.
I’ve got some media that’s 4096x3024 (1.354). I’ve turned on “Use Ratio” in every conceivable place, but it flame still displays the squashed image in both reels and batch.
Is there a very obvious preference I’m forgetting about, or does this require a work around/bug fix?
That is because 4096x3024 at 1.354 is square pixels, so there will be no difference
If you manually enter your desired ratio (if it’s anamorphic, for example), “Use Ratio” should do what you’re expecting it to…
So, for instance, if it was a 1.5x anamorphic lens, multiply 1.354 x 1.5.
Or, in other words, your color house screwed you. Or someone started working on it as if it were square pixels and now you have to manually manage that entire process. Boo.
This is one of my biggest pet peeves.
It was, indeed, an anamorphic lens.
I’m picking up someone else’s work, so I think the appropriate tagging on conform hadn’t taken place to inform “Use Ratio” on what to do. I hadn’t considered this step, as every anamorphic job I’ve ever done was mine from the beginning (and it’s been a while)
With the understanding math has never been my strong suit and resolution vs pixel aspect ratios requires an inordinate amount of brain power on my behalf, can you explain to me how you determined 4096x3024 at 1.354 is square pixels?
DAR = Display Aspect Ratio
PAR = Pixel Aspet Ratio
H = Image Height
W = Image Width
H / W x PAR = DAR
1920 / 1080 x 1 = 1.778
720 / 486 x 0.9 = 1.33
H x W x PAR = DAR
Thank you for this @randy !!
Thank you for your response.
I understand that 4096/3024 will give you the pixel aspect ratio, but what about “4096/3024=1.354” suggests square pixels?
In other words, how to you look at the above math equation/result and infer “That has a square pixel aspect ratio” from it?
I feel like there’s a key piece of information I don’t have.
Square pixels are simply width/height and are the presumptive default of all images. Basically it’s safe to assume that your pixels will be square because square pixels are the most basic pixels.
So if your image looks squished when displaying it at the default w/h aspect ratio, it means that your pixels are anamorphic. They’re stored as regular old squares, but need to be stretched out by their Pixel Aspect Ratio (PAR) to display correctly.
The PAR is a bonus width scale of the display ratio. So for regular anamorphic (2.0) you get something like this:
whereas if you have shitty as NTSC’s sligtly narrow pixels it looks like this
Thanks @andy_dill & @randy
This is making more sense now. It seems I was mixing up my pixel aspect ratio and display aspect ratios.
Thanks for taking the time to type all this out!
We quite often loose our metadata once the material has been run through the grade
That’s because it’s rendered wrong. :-). You didn’t lose it. It didn’t get misplaced. Someone broke it.
Lustre is very frequently guilty of this.