Jump to content
Hash, Inc. Forums
Sign in to follow this  
Maniac

Green Screen Fun

Recommended Posts

It looks like the "remove green" has worked well.

 

However, I'll note that if you are adding animation on top of live video you can get the same result without green screen by rendering with an alpha channel.

Share this post


Link to post
Share on other sites

It looks like the "remove green" has worked well.

 

However, I'll note that if you are adding animation on top of live video you can get the same result without green screen by rendering with an alpha channel.

 

However....I must say that there are times when rendering a green or "blue" screen with a render is necessary. Hash's "Alpha" channel is not always functioning on import into certain Apps depending on what file type you rendered it in.

 

New versions of A:M often change how these exports work, etc. So it is important when using hash to test a few frames with the post App of your choice.

For instance, if you render a .TGA out of Hash with an Alpha and then import it into Adobe Photoshop CS4, the Alpha channel isn't going to be Automatically

"doing it's masking thing." And it takes steps to get that to work within

 

This same Alpha channel in the .TGA will however work in After Effects, but you must set the frames to "use" alpha.

 

The worst case is when you have to somehow "Re-mask" things based on a channel that exists within the file, rather than it being interpreted automatically.

 

I like using .PNG format because it seems to transfer better into more external Apps with the least amount of troubles.

Share this post


Link to post
Share on other sites

I will grant you that the difference in the way Adobe Photoshop and Adobe After Effects work with alpha channels is a source of frequent confusion.

Share this post


Link to post
Share on other sites
I will grant you that the difference in the way Adobe Photoshop and Adobe After Effects work with alpha channels is a source of frequent confusion.

 

 

Well said.
New versions of A:M often change how these exports work, etc

 

File output from A:M has been very consistent (one of the benefits of code not changing over the years). If you had said, "New versions of A:M do not often change how these exports work" I'd be in full agreement. Any bugs that are identified get quickly addressed. :)

 

I am Playing with free trial program called Wondershare Filmora

 

Downloaded and played around with it a bit. Thanks for the heads up.

There are some drag/drop effects in there that I haven't seen readily available in other/similar programs.

Share this post


Link to post
Share on other sites

I'll add this because it relates to the topic of adding color into an image only to take it away later (via chromakeying or whatnot).
In another forum I was curious about the difference between RGBA and RGBM. The later of which is what is generally referred to in the Japanese animation industry.
Of note is that the entire industry basically goes through that extra process of adding color (pure white in their case) only to remove it later (with a few exceptions as noted in the text below).

Shun Iwasawa is a technical director that was with Studio Ghibli for many years and now heads up development on the OpenToonz software (primarily through grants from the Japanese Government) and through agreement with the originators of the Toonz software which OpenToonz was extended by Studio Ghibli. At any rate, here is a little of what he had to say relating to the use of the M (that is to say 'Matte') channel in RGBM/RGBA:

(Note that the initial quoted text is from me. The follow up/answer is from Iwasawasan)

 

I must assume in Japan the use of full M255 is avoided for other 'white' color to avoid those areas going transparent as white pixels are replaced with transparent pixels upon compositing.


Exactly. In Japanese animation production, they never use "255-white" color (= R255 G255 B255 M255) for any part of characters, since it is reserved for transparent area. Instead they use light gray for "white " part such as the white of the eye, the head of Gundam, etc.
Actually avoiding to use 255-white color in characters is more for visual effect, than for software restriction written in the above. Any light effect applied on the 255-white pixels will become useless since all channels are already saturated. So they use light gray, in order to leave dynamic range for representing "brighter than white" area.

 


So, similarly, if/when we add color to an image that will later be taken back out we must take some care to make sure it is not a color that will be inadvertently removed during the composting stage.
It is interesting to note also that this 'extra step' they are performing is largely through tradition in much the same way dealing with transparency in Photoshop; that's the way it has always been. Of course, the desire to get at higher dynamic range is an important aspect to consider and Shin emphasizes that as current industry practice. Of note, this is unlike adding green, blue or other color to an image with a goal of removing it later. There is little to no point in doing that unless... the program under consideration can't be made to work with alpha channels.

In the case of Japanese animation many studios have a fairly good reason for maintaining the workflow because hand drawn images on paper are still scanned into computers and drawings on paper do not have transparency. As such that has to be dealt with at some stage. However, this is not the case with drawings made in digital programs! (Footstomp in case there is a test later) *IF* we can have transparency from the outset there is rarely a need to get rid of that transparency... replacing it with a temporary color... and then removing it again later. To do this makes very little sense.

One of the problems with use of the Alpha Channel/Transparency is that not all programs display that transparency in a way that users can interact with it. This is why Photoshop create those 'crawing ants' so that masks could be readily seen. But a mask/matte and transparency is not neccesarily the same thing. Even A:M has some issues with this in that transparency may appear as black in some cases (such as preview images in the Project Workspace). This can lead users to mistakenly think their background is black when in fact it is completely transparent. Many programs use a checkerboard pattern to aid in the identification of transparency.

All of this is further complicated by modern image formats (such as EXR) that store additional data in the Alpha Channel and perhaps especially for EXR 2.0 that allows depth and multiple images to be stored within the same channel in arbitrary manner. The film industry has been trying to standardize the expanded use of the Alpha Channel and has made great strides but to date no standard has been set.

Share this post


Link to post
Share on other sites

Create an account or sign in to comment

You need to be a member in order to leave a comment

Create an account

Sign up for a new account in our community. It's easy!

Register a new account

Sign in

Already have an account? Sign in here.

Sign In Now
Sign in to follow this  

×