I followed your steps of applying a chroma key to a green screen clip on track 2, then splitting the clip and adding every keyframe in the Fix/Enhance section (including Color Enhancement) a few seconds in and I don't see the issue your recording shows.

What happens if you turn off Open CL and then Hardware Decoding from Preferences | Hardware Acceleration?

You may also want to upload your green screen sax player clip as there may be an issue with it. Do you have Apple QuickTime or the QTLite codec installed?

Also, if you're not going to change every single one of the other settings, there's no need to set an initial keyframe in each one.

Quote I followed your steps of applying a chroma key to a green screen clip on track 2, then splitting the clip and adding every keyframe in the Fix/Enhance section (including Color Enhancement) a few seconds in and I don't see the issue your recording shows.

What happens if you turn off Open CL and then Hardware Decoding from Preferences | Hardware Acceleration?

You may also want to upload your green screen sax player clip as there may be an issue with it. Do you have Apple QuickTime or the QTLite codec installed?

Also, if you're not going to change every single one of the other settings, there's no need to set an initial keyframe in each one.

No, Apple QuickTime or the QTLite codec is not installed. Try to narrow down this issue. Here is what I found.

• A newly-created project has the same issue


• After all keyframes (including Color Enhancement) are created at 10 sec, the issue (background becomes black) is recreated. Now if I change Color Enhancement default value 50 to 0, the background is changed from black back to "transparent" (i.e. the issue is gone).


• The same issue occurs even I only create Color Enhancement keyframe at 10 sec. But again, if Color Enhancement default value 50 is changed to 0, the issue is gone

Thanks & regards.

This may be something to report to CL tech support. You didn't mention whether changing the Hardware decoding or OpenCL settings have any effect.

As far as I'm aware, Quicktime or QT Lite are required for MOV clips and there's a chance that installing one of these codecs/support packages will resolve your issue.

Again, if you could share that specific clip here that would let other people see if they encounter the same issues or not on their systems.

Quote This may be something to report to CL tech support. You didn't mention whether changing the Hardware decoding or OpenCL settings have any effect.

As far as I'm aware, Quicktime or QT Lite are required for MOV clips and there's a chance that installing one of these codecs/support packages will resolve your issue.

Again, if you could share that specific clip here that would let other people see if they encounter the same issues or not on their systems.

I created a new and very small project that can reproduce this issue. Attached zip file contains a clip showing the steps on how to reproduce the issue. It also contains all other files including PD project file so you can easily duplicate what I did to see the issue.

Again, after change the default value of Color Enhancement from 50 to 0, this issue disapears. My bold guess is if Color Enhancement didn't have impact/changes in the areas covered by chroma keys, then this issue wouldn't happen.

By the way, OpenCL and HW decoding do not seem having contributions to this behavior. After they are un-selected, the same issue still happens.

Thanks & regards.

Thanks very much for the project. There's no recorded audio in your screen recording but it's clear enough what you're pointing to.

When I open the project on my system, I immediately see the corrupted chroma keyed area. To see whether it might have been something caused by your system, I unchecked the Color Enhancement tool (which also removed its keyframe) and then removed the chroma keys completely.

After adding back the chroma keys, I found that sometimes there would be no impact when adding Color Enhancement while other times I'd see the same problem as you, so it seems that simply checking the Color Enhancement box always affects the chroma key, but sometimes it's much more noticeable.

Ideally, checking the Color Enhancement tool or placing a neutral (unchanged) keyframe would not affect the clip at all, but it appears that some level of "enhancement" occurrs even then. I can't tell if that's intentional or unexpected, but it would be a good idea to report this to CL so they're at least aware of the situation.

Submit a support request here, and be sure to include a link to this forum discussion so they can see everything that's happened and can download your very helpful test project.

As a workaround, produce each clip once you're happy with the chroma key settings and then do all the other edits, like Color Enhance on the new versions.

Quote
Submit a support request here, and be sure to include a link to this forum discussion so they can see everything that's happened and can download your very helpful test project.

As a workaround, produce each clip once you're happy with the chroma key settings and then do all the other edits, like Color Enhance on the new versions.

Thank you for your confirmation. A support request was entered (CS002402086).

Regards.

Quote


I created a new and very small project that can reproduce this issue. Attached zip file contains a clip showing the steps on how to reproduce the issue. It also contains all other files including PD project file so you can easily duplicate what I did to see the issue.

Again, after change the default value of Color Enhancement from 50 to 0, this issue disapears. My bold guess is if Color Enhancement didn't have impact/changes in the areas covered by chroma keys, then this issue wouldn't happen.

By the way, OpenCL and HW decoding do not seem having contributions to this behavior. After they are un-selected, the same issue still happens.

Thanks & regards.

Hi,
I wonder if this is just a question what chromakeying actually tries to do?

I gather that you want to have the ability to allow the colour (or other variables) of, in this case, the stool.
"The final effect would look like color is graduatly changed from 0 sec to 10 sec, and stay unchanged after 10 sec."

On that assumption, then the colors in the stool clip will change from T0 to T10 by using Enhancement, Hue etc..

If you make those changes quite aggressive, just to illustrate the point, you can make the stool very dark, the backdrop very blue and the ground lilac. So the stool clip changes between T0 and T10 quite spectacularly, and not very attractively!

You can see that effect, quite simply, by applying the changes to the clip before applying any chromakey filters.

If you were then to apply a series of chromakey filters, what would you choose to key out?
At T0 it would be greens (as in the sample project) and at T10 it would be blues and lilacs (after applying your color adjustments).

Since chromakey cannot be keyframed, it cannot work correctly.

This is just by way of an illustration of what I think chromakey tries to do.

Perhaps the best way to look at it is to view chromakey as a filter not an edit. Further edits to the clip apply to the clip, not to the filtered view, hence the filter does not always work as intended.

So, assuming you don't want to change the stool clip much, just enhance the color a little etc. etc. perhaps do all that before applying the chromakey, and see if you can get the chromkey to work sufficiently well over the changes you apply.

In effect, that is what optodata suggested but his idea is more "predictable", but I think it will still suffer from the basic problem with large color changes and chromakey technology.

Cheers
PowerDirector Moderator

Quote

Since chromakey cannot be keyframed, it cannot work correctly.

This is just by way of an illustration of what I think chromakey tries to do.

Perhaps the best way to look at it is to view chromakey as a filter not an edit. Further edits to the clip apply to the clip, not to the filtered view, hence the filter does not always work as intended.

So, assuming you don't want to change the stool clip much, just enhance the color a little etc. etc. perhaps do all that before applying the chromakey, and see if you can get the chromkey to work sufficiently well over the changes you apply.

In effect, that is what optodata suggested but his idea is more "predictable", but I think it will still suffer from the basic problem with large color changes and chromakey technology.

Cheers
PowerDirector Moderator

Thanks for your suggestion and information. Yeah, agree that chromakey is a filter not editor. That's also what we feel about it. At least the issue we reported does not affect our work. With PD 19, we can get our job done without problems. Thank you and Optodata for your dedicated support. Much appreciate.

Regards.