I am conforming on 2023.0.1. Offline was cut with cropped 1080P proxies. The Arri footage is 4.5k open gate 1.437 aspect ratio. When the actions from the XML or AAF are applied to the timeline, the Action used the background as the Action size in place of the timeline size that is set to 1080P 10bit. Even if I turn on the resize in front and set it to 1080P and see the proper crop, the Action following it still keeps the Arri LF sizing, thus making the result all squeeze down by 200% in the 1080 frame. Something is wrong here. I do not see this in 2021.X, but I already had built VFX for the offline artist in 2022, so no reverting back without rebuilding all the work completed. I can work around this by copying the clip with timeline FX, putting a BFX on the clip effected, inside the BFX I paste and explode the action and resize, make sure the resize is set correctly, and boom. All is well. Now doing this for 100 shots is crazy, but that may be my day. Anyone know of a new setting for behavior that would cause this? Thanks!
I run in to this weirdness as well. I’ve been trying to consistently reproduce it before I try to make a bug report.
The thing that seems to make it happen is an Action from an AAF or XML. It never happens with an Action I create in flame.
So yea… my workaround when I see this is to remove the Action (created by an AAF/XML) and manually recreate the Action. It’s a pain when there’s a lot of shots to do. If it’s an animated Action you can copy/paste the animated channels but you have to make a new fresh Action.
This has been messing with me in 2022.3.1 for the last 6ish months. Agree with Bryan that it’s from AAF Actions.
I work around it by copying the segment to a duplicate track above, removing the Action on the dupe, and then F-dragging the original Action on the bottom segment to the fresh one above. That seems to smack it into realizing what’s going on, and is maybe less of a PITA than doing it in a BFX? Would love to get to the bottom of it.
This sounds like it’s not so much an issue with flame, but a problem with the application generating the aaf/xml, as well as the editor/assistant not checking the right boxes.
It appears right random but I got it on a project now more often to test around a bit.
Drag&Duplicating the clip in the timeline will reset the wrong action setup in both segments immediatly and is a very quick workaround.
this also happens when you reconform to openclips .
Its the biggest issue we have with flame at the moment, data is correctly translated between editorial and flame but all the actions are corrupt and those we need to rebuilt it everytime which is wasting time
A couple of expressions I use that help. I keep prebuilt actions in my explorer list that I liberally drag and drop on my timeline.
if(surface1.lensDistort.centreX<surface1.lensDistort.centreY,100*(1920/(2*surface1.lensDistort.centreX)),100*(1080/(2*surface1.lensDistort.centreY)))
if(surface1.lensDistort.centreX>surface1.lensDistort.centreY,100*(1920/(2*surface1.lensDistort.centreX)),100*(1080/(2*surface1.lensDistort.centreY)))
These expressions are added to the axis scale. One will fit the image vertically, the other horizontally. It’s hard to say which will do which, because I think that is determined by the aspect ration of the image. I keep one of each and if I don’t like what one does, I drop the other. I also add a default axis above the one that has the expression so that once I have matched the image to the size of the dailies, I can then repo as needed. Doing it this way keeps the repo and the resizing in the same action, so that I don’t lose resolution if I need to repo back up to match the reference. If the aaf/xml has repo data I can usually copy that axis and past it into this action effect and parent it to the top.
This expression limits the timeline to 1920x1080. It’s rather self explanatory if you want to change that. I use one that actually detects the timeline resolution, but it is buggy, so I don’t like to share it. This one has stood the test of time fairly well.
And thank you @fredwarren @Slabrie for not restructuring the lens data in action.
this is still a bug in 2025.1.1
we can reproduce it every time on every project we have to trash all the xml- ingested actions and have to manually reframe every shot
its ridicolous.
I am going to be submitting another bug report this week and a support case, its seriously wasting us so much time.
the worst thing is - i have the premiere part under control and we can fix the scaling difference between how the proxies where made and the raw material - all a non issue the scale values in the actions are correct .
Would be a 1 click conform if it wasnt for yhis pesky annoying bug.