Chris Hart
Forum Replies Created
-
If you download the free pro codec folder from Apple, and another free application (I think it’s called Unpack), you can install the prores4444 codec without the upgrade. The details are in another discussion on COW, search prores4444.
Extremism in the pursuit of good edges on the foreground object is no vice.
-
Hi Ted,
Thanks very much for taking the time to check out the comp. Yes, I am simulating a camera pan, because in the full project, we’re simulating a complex zoom/pan over terrain, from several kilometers up to just a few dozen meters; to do the move over one layer would mean a 50000×50000 precomp, which crashes AE. So we’re using the Andrew Kramer scale method, with multiple differently-scaled layers, in addition to some modest camera movements. But when the camera is at maximum “height”, and I change the anchor point so the “zoom in” can scale to a different location from the “zoom out”, the displacement mapping moves in a way I don’t understand.
Yes, you are right about the scaling on the displacement layer. I agree that it doesn’t seem the way to go, but in the file I sent u, just to demonstrate that I couldn’t get it to work, on 2 of the 3 comps in the project , there is an expression moving the displacement map in conjunction with the precomp of the Freeformed layer. You’re right, it doesn’t fix the problem. But in the comp “anchor point problem 3” there is no expression or movmement on the displacement map, yet there’s still an odd shift.
To clarify what I’m trying to achieve: in “anchor point problem 3”, the frisbee-like object seems to move away from the camera, pause, and then zoom back towards the camera, but from a different angle. That angle change, which is meant to simulate the camera moving toward a different point on the frisbee, comes from the keyframed anchor point change in the precomp for the frisbee. On the frame when that anchor point change happens – frame 1;16 – the displacement layer doesn’t follow the anchor point change, so the displacement on the frisbee shifts. I’d like to be able to change the anchor point in the precomp, and have the displacement stay locked to the frisbee, so it has consistent “terrain” during the whole camera move.
Again, I really appreciate you taking the time to think about this.
Chris
Extremism in the pursuit of good edges on the foreground object is no vice.
-
Hmmm…here is the link to the attachment:
4123_anchorpointproblem.aep.zip
Extremism in the pursuit of good edges on the foreground object is no vice.
-
Hi Ted,
Attached is a project that shows the displacement layer shifting on the frames where the anchor point changes. There are a couple comps in the project, each a different attempt to stop the shifting, but each a failure.
Thanks so much for your attention!
Chris
Extremism in the pursuit of good edges on the foreground object is no vice.
-
Correction, sorry. The contrast adjustment is 7 out of 100 in the Brightness and Contrast Compressor filter.
Extremism in the pursuit of good edges on the foreground object is no vice.
-
Gamma Shift in h264 from fcp.
One way to make your h264 quicktimes on the desktop match the way your timeline looks in fcp:
When exporting to h264, use Compressor, and use a couple filters. A 1.1 gamma filter adjustment, along with a .7 contrast adjustment, helped my last sequence look the same in fcp and in the h264 qt. The qt looked the same on Daily Motion, too. Not sure about youtube yet.
I found this info on another forum, passing it along.
Good luck.
-
I’m in the same boat, right now rendering a 23.976 version of the 29.97 created w/ timestretch/timewarp. Long render due to motion blur. But I want to mention: these days we do rolls for hd 24p projects. With the monitor refresh rate of 60 or greater, there is no way to avoid flicker on a 24p project with whitish credits rolling up a blackish screen from ae. You can blur, but the flicker will be there. If you don’t use an integer # of pixels per frame (and that expression should say pixels/frame, not pixels/sec) the flicker is much worse, but it will be there because the scan lines are offset from the 23.976 motion (as opposed to coinciding exactly with the 29.97 motion, assuming an even # of pixels/frame).
Or am I wrong?
Chris Hart
https://www.chrishartedits.com
chrishartedits@gmail.com