[Raven Plenty]

It’s worth mentioning something that comes up a lot in 170/200 vs. 150 smackdowns. If you’re going to be doing green screen work, the HPX becomes more important. The 150 only does 4:2:0 chroma subsampling, whereas the 170/200 does 4:2:2 — so that’s better colour resolution (combined with less compression artifacting) which will make for much better green screen results.

If you don’t need the edge on that level, then for regular footage viewed at 100% with the naked eye, there’s (arguably) not a very big difference in the image quality between the two cameras.

[Raven Plenty]

It didn’t, but thanks Mark. Ungrouping the PSD group fixes it though.

Cheers.

[Raven Plenty]

Update: it seems only to be a problem involving PSD graphics imported via “All Layers”. To recreate:

1. Import a PSD onto the canvas, choosing to import “All Layers”. The PSD layers are imported into a group named after the PSD file.
2. Create a new type object within the PSD group. Select it and Group it. It will move.

Anything inside of the Group created when importing the PSD will get messed up when re-grouping within. The solution (yay!) is to Ungroup the PSD group. Even if I re-group the collection of imported objects, the problem is gone. Hallelujah!

Hope that all makes sense. Thanks for your help (and offers to troubleshoot my file).

[Raven Plenty]

No filters or behaviours used – only two things happening here. The little blue triangles scale from 1 to 100% to “pop” into existence; and there’s a feathered mask used to reveal the text boxes with a left-to-right wipe. (I just did a test where I removed the masks, and still the objects move drastically when grouped.)

The “fixed resolution” thing doesn’t help me anyway, since the objects are still in their wrong places after checking that box.

Any other suggestions? I still think it’s a bug.

[Raven Plenty]

No takers yet?

I’ve learned that if I “group” one object, then drag the other objects into that group, things move less. They still move a little bit, but it’s better. Still…this is a major bug, is it not?

[Raven Plenty]

I’ve had frequent transparency issues with PNG in Motion (and FCP), so a different solution is required. I guess I’ll save that for a separate post though.

[Raven Plenty]

[Rafael Amador] “This is the only way to avoid the layers resizing.”

Thanks Rafael, but I have to say again: it’s not a problem with the other (very similar) layers in the same PSD, nor with any other graphics I’ve done.

Edit: I should add that resizing is not the issue here anyway. Please refer to the screenshots I posted earlier.

[Raven Plenty]

[Rafael Amador] “Make sure that all the corners of all the layer have some color information.
If there is any fully transparent corner, pint [paint?] few pixels.”

But I’m not going to paint a few pixels in an area that is supposed to be transparent, and then mask those pixels in FCP. Plus, I tried that and it didn’t work. Plus, all of the other layers in the same PSD file worked fine even though they have the same transparent top portion. Plus, PNG-24 has always worked for me in the past regardless of transparent corners.

I think I have to just let this one go… Random glitch.

[Raven Plenty]

Thanks Nicole but it didn’t work. I believe Alpha channels are not included in PNG files anyway. My impression is that PNG-24 files are supposed to work fine, and that this is just some weird anomaly. I can do a TIF with Alpha channel, or a PSD file – just was hoping I might learn the cause of this issue.

Ah well, thanks all for your input.

[Raven Plenty]

[Nicole Haddock] “Actually, the PNG file needs an Alpha channel (as does a .TIFF). Make sure there’s only one Alpha. If there’s 2, FCP won’t know what to do. “

But the other 4 layers worked, and they’ve always worked for me until this one layer. I’m simply hiding and revealing each layer as needed, then exporting a PNG for each layer via Save For Web.