Alpha channel distinction

I am have Flash 2004 MX. I plan to purchase 9 when CS3
releases and I would like to do some alpha channel work.before
then. If I use Sorenson's ON2 plug-in to create an flv with an
alpha channel - and then import it to FLASH 2004 MX - will the
aplha channel be recognized? Or, would it be necessary to pony-up
for Flash 8 just a few months before CS3 arrives, and then have to
pay again for Flash 9 in CS3?

rdl33 wrote:
Alpha Channel works well with solid colours but leaves a lot of "blotches" in textured surfaces. Apple forgot to include an Eraser. Do we have to move the graphic to Photoshop to finish the job?
There are certainly images where only Photoshop or another image editor can do a clean job. However, depending on the shape of the area you want to remove, you may be able to simulate it by adding geometric shapes that cover the bad areas. There are other tricks, like taking screen shots or copying part of the picture using Preview, and so on. It really depends on the image and the shape.
When I need a good image editor I use Photoshop. When I want a free one to install temporarily on a computer that does not belong to me, I use gimp out of old habit, but there are other ones out there.

Similar Messages

Automator or Applescript using png files with alpha channel

I have hundred of png files with alpha channel.
I want to suppress alpha channel.
How can i do it using Automator or Applescript ?
Thank you very much.

You can use the free command line image processing tool ImageMagick in your Applescripts or Automator workflows, as well as from a Terminal shell.
You can download ImageMagick from http://www.imagemagick.org, but Cactuslab has simplified installation by putting together an installer package. It’s available at http://cactuslab.com/imagemagick/. Download the package and double-click on it. Follow the instructions to install. It will install ImageMagick into /opt/ImageMagick and add it to your $PATH by creating a file in /etc/paths.d/. Restart your computer for the changes to take effect.
The two ImageMagick commands we’re concerned with are “convert” and “mogrify”. Convert is more efficient for multiple and piped operations on the same image file, and mogrify is more efficient for batch processing. Generally speaking, convert will output a file separate from the input file. Unless a path is specified, mogrify will overwrite the input file with the output file. An important distinction.
You can perform various operations on the alpha channel using arguments after either the convert or mogrify command. Two of the available arguments are:
-alpha off - Disables the image's transparency channel. Does not delete or change the existing data, just turns off the use of that data.
-alpha remove - Composite the image over the background color.
Also of use are the -flatten and -background options:
-flatten - overlay all the image layers into a final image and may be used to underlay an opaque color to remove transparency from an image.
-background - sets the background color.
Start off using the convert command with a single image to see the effect and adjust to your liking. Once you’ve achieved the desired outcome, then use the mogrify command to batch process the chosen images.
Before getting into how to use Automator or Applescript in your workflow, use Terminal and the command line to see the effect on a single image. Copy one image to your ~/Desktop. In Terminal change the directory to ~/Desktop by typing the following command and pressing the Enter key:
cd ~/Desktop
Then choose the option you are looking for, -alpha remove for instance, type the following command and press the Enter key:
convert input-photo.png -alpha remove output-photo.png
You can check the alpha channel (transparency) and background in the Preview app, go View > Show Image Background from the menu bar.
Once you’re ready to batch proces, place all the photos you want to convert with the same command into one folder. Copy the folder to your ~/Desktop. Let’s assume you’ve labeled the folder “InPhotos”. It’s prudent to manipulate copies in case something goes amiss. In that event you can copy the folder with the originals again and start over. Create a new empty folder on your ~/Desktop and call it “OutPhotos”. Let’s also assume your home directory is called “Me”. The following command will process the photos from the InPhotos folder and put them in the OutPhotos folder:
mogrify -alpha remove -path /Users/me/Desktop/OutPhotos/ /Users/me/Desktop/InPhotos/*png
According to Apple Technical Note TN2065:
"when you use just a command name instead of a complete path, the shell uses a list of directories (known as your PATH) to try and find the complete path to the command. For security and portability reasons, do shell script ignores the configuration files that an interactive shell would read"
So, you need to use the full path to to ImageMagick commands, unlike in the shell where you can just use the command name.
To batch process using Automator, use the “Run Shell Script” action (note: retain the single space at the beginning of the last line):
/opt/ImageMagick/bin/mogrify \
-alpha remove \
-path /Users/Me/Desktop/OutPhotos/ \
/Users/Me/Desktop/InPhotos/*png
To batch process using Script Editor (Applescript), use the “do shell script” command:
do shell script "/opt/ImageMagick/bin/mogrify -alpha remove -path /Users/pd/Desktop/OutPhotos/ /Users/pd/Desktop/InPhotos/*png"
Further info on ImageMagick:
http://www.imagemagick.org/script/command-line-options.php#alpha
http://www.imagemagick.org/Usage/masking/#remove
http://www.imagemagick.org/index.php
http://www.imagemagick.org/script/command-line-tools.php
http://www.imagemagick.org/script/command-line-options.php
Examples:
The original PNG image:
-alpha off:
-alpha remove:
-background black -flatten:
-background blue -flatten:
-channel alpha -evaluate Divide 2:
-channel alpha -evaluate Divide 2 -background black -flatten:

How do i create an alpha channel to place into edge animate?

HowHow do i create an alpha channel compatible with edge animate?

I don't use Edge, but since it is a web tool it stands to reason it would use standard web techniques, meaning it would rely on built-in transparency functions of formats like PNG and GIF, which you can easily produce by using Save for Web after creating normal transparency on a layer in Photoshop. No extra Alpha channel or otehr extra steps required. Perhaps Edge even has some stuff that does the conversion on the fly by allowing you to open a native PSD like in Dreamweaver, but beyond that I don't see what else it could/ would do - all the features it can provide are limited by standard specifications for HTML, CSS and JavaScript. There is simply no way to do something sensible with a TIFF in a browser, if you get my meaning .
Mylenium

How can I see the alpha channel in the channels palette?

Hello, mi format plugin loads a rgba image. I see it with transparency, that's ok, but when I go to the channels tab I only see 4 items (RGB, Red, Green and Blue).
How can I see the alpha channel of my file in the channel tab?
Thanks!

OK, something must be wrong... but I don't find it!
That's my whole code (resumed). I ommit some code (saving file code (not used) or main function, where I only call te "DoSomething" functions. You can see that I use layers. The DoReadContinue function is only used to show the preview.
In the DoReadStart function I set the parameters for the layers (and the preview), and I fill the "data" and "layerName" params in the DoReadLayerContinue function. I hope you can understand the code!
const int32 IMAGE_DEPTH = 32;
SPBasicSuite * sSPBasic = NULL;
SPPluginRef gPluginRef = NULL;
FormatRecord * gFormatRecord = NULL;
intptr_t * gMxiInfoHandle = NULL;
MXIInfo* gMxiInfo = NULL;
int16 * gResult = NULL;
#define gCountResources gFormatRecord->resourceProcs->countProc
#define gGetResources   gFormatRecord->resourceProcs->getProc
#define gAddResource    gFormatRecord->resourceProcs->addProc
CmaxwellMXI* cMax;
static void DoReadPrepare (void){
    gFormatRecord->maxData = 0;
static void DoReadStart(void){
    char header[2];
    ReadScriptParamsOnRead (); // override params here
if (*gResult != noErr) return;
    // Read the file header
    *gResult = SetFPos (gFormatRecord->dataFork, fsFromStart, 0);
    if (*gResult != noErr) return;
    ReadSome (sizeof( header ) * 2, &header);
    if (*gResult != noErr) return;
// Check the magic number for avoid no-mxi files
    int headerID = CheckIdentifier (header);
    if( headerID != HEADER_MXI ) *gResult = formatCannotRead;
if (*gResult != noErr) return;
// The file is OK. Let's continue to obtain the data of the image.
cMax = new CmaxwellMXI( 0 );
strlen((char*)gFormatRecord->fileSpec->name);
gMxiInfo->filename = _strdup((char *)gFormatRecord->fileSpec->name + 1);
bool res = cMax->getMXIIInfo(
                (const char*)gMxiInfo->filename,
                gMxiInfo->width, gMxiInfo->height,
                gMxiInfo->burn, gMxiInfo->monitorGamma, gMxiInfo->iso,
                gMxiInfo->shutter, gMxiInfo->fStop, gMxiInfo->intensity,
                gMxiInfo->scattering,
                gMxiInfo->nMultilightChannels, gMxiInfo->lightNamesList,
                gMxiInfo->availableBuffersMask,
                gMxiInfo->widthPreview, gMxiInfo->heightPreview,
                gMxiInfo->bufferPreview);
if(!res) return;
// Check the available extra buffers
int count = 0;
if( gMxiInfo->availableBuffersMask & CmaxwellMXI::ALPHA_BUFFER ){
    // We will use that string to obtain later the desired extra buffer.
    gMxiInfo->extraBuffersList[count] = "ALPHA";
    gMxiInfo->hasAlpha = true;
    count++;
else{
    gMxiInfo->hasAlpha = false;
gMxiInfo->nExtraBuffers = count;
switch( IMAGE_DEPTH ){
case 8:
      gMxiInfo->mode = plugInModeRGBColor;
      break;
case 16:
      gMxiInfo->mode = plugInModeRGB48;
      break;
case 32:
      gMxiInfo->mode = plugInModeRGB48; //96 gives me an error
      break;
// SET UP THE DOCUMENT BASIC PARAMETERS.
VPoint imageSize;
if( gFormatRecord->openForPreview ){
    // Preview always RGB8.
    imageSize.v = gMxiInfo->heightPreview;
    imageSize.h = gMxiInfo->widthPreview;
    gFormatRecord->depth = 8;
    gFormatRecord->imageMode = plugInModeRGBColor;
    gFormatRecord->planes = 3;
    gFormatRecord->loPlane = 0;
    gFormatRecord->hiPlane = 2;
    gFormatRecord->colBytes = 3;
    gFormatRecord->rowBytes = imageSize.h * gFormatRecord->planes;
    gFormatRecord->planeBytes = 1;
else{
    // Configure the layers. All RGBA32.
    imageSize.v = gMxiInfo->height;
    imageSize.h = gMxiInfo->width;
    gFormatRecord->depth = IMAGE_DEPTH;
    gFormatRecord->imageMode = gMxiInfo->mode;
    gFormatRecord->layerData =
        2 + gMxiInfo->nMultilightChannels + gMxiInfo->nExtraBuffers;
    gFormatRecord->planes = 4; // RGBA.
    gFormatRecord->loPlane = 0;
    gFormatRecord->hiPlane = 3;
    gFormatRecord->planeBytes = IMAGE_DEPTH >> 3;
    gFormatRecord->rowBytes = imageSize.h * gFormatRecord->planes * ( IMAGE_DEPTH >> 3 );
    gFormatRecord->colBytes = gFormatRecord->planes * ( IMAGE_DEPTH >> 3 );
    gFormatRecord->transparencyPlane = 3;
    gFormatRecord->transparencyMatting = 1;
    gFormatRecord->blendMode = PIBlendLinearDodge;
    gFormatRecord->isVisible = true;
SetFormatImageSize(imageSize);
gFormatRecord->imageHRes = FixRatio(72, 1);
gFormatRecord->imageVRes = FixRatio(72, 1);
VRect theRect;
theRect.left = 0;
theRect.right = imageSize.h;
theRect.top = 0;
theRect.bottom = imageSize.v;
SetFormatTheRect(theRect);
// No resources for now.
if (sPSHandle->New != NULL) gFormatRecord->imageRsrcData = sPSHandle->New(0);
gFormatRecord->imageRsrcSize = 0;
    return;
/// Called for prewiew only.
static void DoReadContinue (void){
    // Dispose of the image resource data if it exists.
    DisposeImageResources ();
if( gFormatRecord->openForPreview ){
    VPoint imageSize = GetFormatImageSize();
    gFormatRecord->data = gMxiInfo->bufferPreview;
      if (*gResult == noErr) *gResult = gFormatRecord->advanceState();
    if( gFormatRecord->data != NULL ){
      delete[] (Crgb8*)gMxiInfo->bufferPreview;
      gMxiInfo->bufferPreview = NULL;
      gFormatRecord->data = NULL;
// De momento nos olvidamos de los icc profiles [TODO]
    //DoReadICCProfile ();
static void DoReadFinish (void)
    // Dispose of the image resource data if it exists.
    DisposeImageResources ();
    WriteScriptParamsOnRead (); // should be different for read/write
// write a history comment
    AddComment ();
// Clean some memory.
if( gMxiInfo->lightNamesList != NULL ){
    for( unsigned int i = 0; i < gMxiInfo->nMultilightChannels; i++){
      if( gMxiInfo->lightNamesList[i] != NULL ){
        delete[] gMxiInfo->lightNamesList[i];
        gMxiInfo->lightNamesList[i] = NULL;
    delete[] gMxiInfo->lightNamesList;
    gMxiInfo->lightNamesList = NULL;
if( gMxiInfo->bufferPreview != NULL ){
    delete[] gMxiInfo->bufferPreview;
    gMxiInfo->bufferPreview = NULL;
if( gMxiInfo->filename != NULL ){
    delete[] gMxiInfo->filename;
    gMxiInfo->filename = NULL;
if( cMax != NULL ){
    delete cMax;
    cMax = NULL;
static void DoReadLayerStart(void){
// empty
static void DoReadLayerContinue (void){
int32 done;
    int32 total;
VPoint imageSize = GetFormatImageSize();
// Set the progress bar data
done = gFormatRecord->layerData + 1;
total = gMxiInfo->nMultilightChannels + gMxiInfo->nExtraBuffers + 2;
// Dispose of the image resource data if it exists.
DisposeImageResources ();
uint32 bufferSize = imageSize.v * gFormatRecord->rowBytes;
int nPixels = gMxiInfo->width * gMxiInfo->height;
char* lightName = NULL;
// SET THE BLACK BACKGROUND
if( gFormatRecord->layerData == 0 ){
    gFormatRecord->data = (void*)new byte[bufferSize];
    for( int i = 0; i < nPixels; i++ ){
      ((float*)gFormatRecord->data)[ i * 4 ]     =
      ((float*)gFormatRecord->data)[ i * 4 + 1 ] =
      ((float*)gFormatRecord->data)[ i * 4 + 2 ] = 0.0;
      ((float*)gFormatRecord->data)[ i * 4 + 3 ] = 1.0;
    // Set the layer name.
    gFormatRecord->layerName = new uint16[64];
    gFormatRecord->layerName[0] = 'B';
    gFormatRecord->layerName[1] = 'a';
    gFormatRecord->layerName[2] = 'c';
    gFormatRecord->layerName[3] = 'k';
    gFormatRecord->layerName[4] = 'g';
    gFormatRecord->layerName[5] = 'r';
    gFormatRecord->layerName[6] = 'o';
    gFormatRecord->layerName[7] = 'u';
    gFormatRecord->layerName[8] = 'n';
    gFormatRecord->layerName[9] = 'd';
    gFormatRecord->layerName[10] = '\0';
// LOAD THE LIGHT LAYERS
else if( gFormatRecord->layerData < gMxiInfo->nMultilightChannels + 1 ){
    void* lightBuffer = NULL;
    void* alphaBuffer = NULL;
    byte foob;
    dword food;
    // Get the light buffer.
    bool res = cMax->getLightBuffer(
                           (char*)gMxiInfo->filename,
                           gFormatRecord->layerData - 1, IMAGE_DEPTH,
                           lightBuffer,
                           gMxiInfo->width, gMxiInfo->height, lightName);
    if(!res){
      *gResult = readErr;
      return;
    if( gMxiInfo->hasAlpha ){
      // Get the alpha buffer.
      res = cMax->getExtraBuffer(
                            (char*)gMxiInfo->filename,
                            "ALPHA", IMAGE_DEPTH, alphaBuffer,
                            food, food, foob);
      if(!res){
        *gResult = readErr;
        return;
    else{
      alphaBuffer = (void*)new float[ gMxiInfo->width * gMxiInfo->height * 3 ];
      for( int i = 0; i < nPixels; i++ ){
        // Only need to set the red channel.
        ((float*)alphaBuffer)[ i * 3 ] = 1.0;
    // Put them together.
    gFormatRecord->data = (void*)new byte[bufferSize];
    for( int i = 0; i < nPixels; i++ ){
      ((float*)gFormatRecord->data)[ i * 4 ]     = ((float*)lightBuffer)[ i * 3 ];
      ((float*)gFormatRecord->data)[ i * 4 + 1 ] = ((float*)lightBuffer)[ i * 3 + 1 ];
      ((float*)gFormatRecord->data)[ i * 4 + 2 ] = ((float*)lightBuffer)[ i * 3 + 2 ];
      ((float*)gFormatRecord->data)[ i * 4 + 3 ] = ((float*)alphaBuffer)[ i * 3 ];
    delete[] (float*)lightBuffer;
    delete[] (float*)alphaBuffer;
    // Set the layer name.
//LOAD THE EXTRA CHANNELS
if( ... ){
//READ THE RENDER BUFFER
if( ... ){
// User can abort.
if (gFormatRecord->abortProc()){
      *gResult = userCanceledErr;
      return;
// Commit the layer.
if (*gResult == noErr) *gResult = gFormatRecord->advanceState();
// Update the progress bar.
(*gFormatRecord->progressProc)( done, total );
// Free memory.
if( gFormatRecord->data != NULL ){
    delete[] (float*)gFormatRecord->data;
    gFormatRecord->data = NULL;
if( lightName != NULL ){
    delete[] lightName;
    lightName = NULL;
static void DoReadLayerFinish (void)
// Nothing to do.
And that's the image that I obtain loading a 8 layer image:
The layers have transparency (when I set "transparencyPlane" to -1, or 0, or 1, or 2, or 3, or 4....., I got the same result!). The blending mode is still "normal". I had set it to "linear dodge" The "isVisible" param works OK.
Alpha 1 is still black.
Is possible that I need to set something in the .r file? I had to add "FormatLayerSupport { doesSupportFormatLayers }," to manage layers, for instance.

Can no longer import QT files with alpha channel

I have been using these client supplied QT with alpha channel files just fine for weeks, then all of a sudden, after a crash the other day, I was unable to open sequences with these files and exoprt them, the exporter would just freeze. the clips played in the timeline, but VERY sluggish.
On the reccomendation of a few posts around here, I removed the clips from the project, and now I cannot import them back in, I get a "the importer reported a generic error" message. I am able to open in QT pro and export to a new file that will import to PPro, but I lose the alpha channel.
As always, I'm up against a deadline and any help would be greatly appreciated.
I have installed QT 7.07, no help.
I'm on a windows 7 machine running CS master collection 5.0, Quad core AMD with 8 gig RAM.
These files worked fine just days ago!!!!
BTW, I just switched over to Premiere a few months ago and to honest I can't understand how anyone would stick with this buggy software, as a professional I've never used anything this bad before.

Welcome to the forum.
Try these. Attempt to re-import after each one:
Clean the media cache database via Edit | Preferences | Media
If step 2 doesn't work, then find all the .qtindex, .mpgindex, .cfa and .pek files associated with the media that's supposed to be in your project and delete them. Then clean the media cache database again.
Launch Pr and while it's launching, hold down the Alt + Shift keys until the Welcome screen appears. Alt resets your preferences and Shift resets the plug-in cache.
To address the other issues you say you've been having with Pr, you should start a different thread (or threads). Coming from other editors, there may be a difference in the way Pr does things that produce unexpected results that may be seen as bugs. More serious issues, such as crashes, can often be caused by 3rd-party hardware like AJA, Matrox or BlackMagic and the associated drivers. Outdated or incorrect drivers for audio and video cards can also cause problems. I recommend that you start troubleshooting those areas first.
Other issues may have workarounds. If you have serious, reproducible problems that have no workaround, then please file bug reports here:
Adobe - Feature Request/Bug Report Form
-Jeff

Is apple going to address the lack of alpha channel support in Keynote 6

Any updates of when Apple will address the lack of Alpha channel support for Keynote 6?

Thanks for the prompt reply, Gary. I am specifically talking about quicktime animations (.mov files) with clear backgrounds. When they play back in Keynote, the backgrounds are black.

No Method of Batch Export for Clips with Alpha Channels?

Good morning,
As many a flustered editor has eventually discovered, in order for FCP to export sequences with alpha channels to a 32-bit format, the timeline has to be un-rendered at the time of export, or else the transparent parts will appear black in the outputted file. This sort-of makes sense if you know how FCP and render files work, but in a perfect world I think I'd have designed the export interface a bit differently. Now that I think about it, I'm actually working in an Animation (Millions of Colors +) sequence, so converting transparent areas to black makes no logical sense at all.
Anyway, I have several sequences that I would like to export as 32-bit TGA QuickTime files, preserving their transparency. If I Export Using Compressor, the process results in pre-rendering of the sequence, turning the transparent areas black. The same problem occurs if I export QuickTime reference movies from FCP and open them directly with Compressor.
Does anyone know of a way to avoid this silly phenomenon or am I stuck individually exporting each sequence from FCP, one...at.......a................time?
Thanks,
Zap

Thanks, Andy, "Batch Export" eventually did the trick!
I forgot about that tool because I've never actually had to use it before! After playing around with it for a while, I found that as long as the sequence settings for each sequence in the batch are set to a codec with an activated alpha channel, it works just fine.
Thanks again,
Zap

Why can I no longer export alpha channels in the new FCPX update (10.0.6)?

While the new update is rich with new goodies- I am having some issues doing some things. My main concern is the inability to export alpha channels in the 10.0.6 updated version of FCPX.
I followed the following steps, same as before the update.
I used the Keying effect to remove the greenscreen and did some cleanup using the "sample color" refining tool.
I cropped and resized the clip so that the actor is the correct size for my clip.
Now it looks great in FCPX, except that I now need to put that footage into Motion 5 and do some motion tracking and match move.
I export the keyed clip as Apple Pro Res 4444
Now when I import that file into Motion 5 everything that is supposed to be transparant is black!
Is there an additional setting in the new version that I need to fix in order to export alphas? Is there a new way to do it?
I am operating Mountain Lion, OSX Version 10.8.2 with a 2.66 GHz Quad-Core Intel Xeon processor.
Thank you so much! This is a key element in almost all the projects I do and now I am stuck!

You got me curious so had to test and validate some of the above, forgive me if I go a little OT in the process.
Have you set your background to checkerboard, I find psycologically this makes a difference, though in exporting it does not...
screen grab below, from 422 timeline, showing original, exported 444 and then imported file comp'd in and scaled down for differentiation in FCPX, note that the project render parameter is actually set to 422 NOT 444 as fox_m suggested, it still works.
This one below shows the above scenario exported 444, with background set to black in pref's, note the overlap showing transparency, again in FCPX. This is purely to illustrate that the checkerboard and black backgrounds are not relevant, only that the 444 on export is relevant.
Hopefully this illustrates that cropping and 444 exports are working.
Tony

Photoshop CC is not showing save "Alpha Channels" to be checked!

This hasn't happened before! As in... it didn't happen as recently as yesterday.
I have a 3 layer image, 2 of them with a large transparent area. I will be importing this into After Effects.
It allows me to check "layers" but not to preserve the transparency. "Alpha Channels" is greyed out.
When I import into AE, even in the media browser the transparency is gone. The transparent area is now black. Ditto when I drag it into the composition canvas.
Mode = RGB, 18 bit
When I import the files from yesterday that *did* preserve the transparency, they still keep the transparency. So I know it's not a problem in AE.
This is where it gets super weird. When I take yesterday's file, open it, and try to save it under a new name -- TODAY IT DOESN'T ALLOW ME TO CHECK "ALPHA CHANNELS".
What have I done to take this option away?

HOLY CRAP -
Indeed, I did not have that.
So I added a channel, and it automatically showed up as Alpha 1...... and my whole image turned red.
When I turned off the image channel, it went back to normal.
Am I possessed?

AppleScript copy alpha channel from one document to a second document

I have two documents. One with Alpha Channels, the other with none. I am trying to copy the alpha channels from one document into the second.
When I use the following in PS 6, the action duplicates the channels in the same document, not in the second document. I am using PS 6 with both documents open in tabs. Any help appreciated.
tell application "Adobe Photoshop CS6"
set x to document 1
set y to document 2
set cc to number of channel of current document
repeat with i from 5 to cc
duplicate channel i of x to y
end repeat
end tell

I can now copy-paste text frames and linked graphics from one document to another using snippets, but embedded images still don't work.
If I embed an image from a pdf file it works but not for jpeg images. When I open the new document (for which I placed the snippet) in InDesign, there is a frame (with a dark grey background and a diagonal cross) shown, but no contents. The place() method did not throw an exception. What am I doing wrong?
Chris.

More CS 5 - ProRes 4444 Alpha channel nonsense

Hi:
Quicktimes I render out of After Effects CS 5 using the ProRes 4444 codec are tagged as having an alpha channel even though my settings in the Output Module are RGB and Trillions of Colors. NOT RGB + Alpha and Trillions of Colors+. It doesn't matter whether my project is 8 bit or 16 bit.
When I bring such movies back into AE it shows them as having an alpha channel (Trillions of Colors+). If I do a Get Info in QT player it shows Millions of Colors+, and FCP shows them as having an alpha, too.
I just upgraded to Snow Leopard 10.6.8 (figured it was safe after two years) and in the process switched full time to CS 5 (I only used it in the past to open other's projects). I never had these issues with CS4. I have not installed any AJA codecs into this new OS (clean install over wiped HD).
This appears to be the opposite of the problem most have been having, which is AE won't generate an alpha in ProRes 4444 without moving codecs and other nonsense.
The reason this is a problem is because when I bring these Quicktimes with faux alphas into FCP for editing I can't export a reference movie. FCP rewrites the whole timeline.
Haven't these CS 5/ProRes 4444 codec/Alpha channel issues been going on for over a year? Do I have to buy CS 5.5 to get this to work correctly?
Thanks.
Shawn Marshall
Marshall Arts Motion Graphics

PR422HQ is way overkill for 99% of the video and film producers in the world. It's there for a specific elite of the entertainment biz, those who work in 4k on 64bit systems, I guess, that' ain't me! It's one of those "if you have to ask, you can't use it" sort of things. Anyone who uses the advanced features of the ProRes family knows why. That's the theory. In my practical experience over on the FCP forum at Apple, 99% of those using ProResHQ believe they are improving their original footage.
Apple ProRes 4444
The Apple ProRes 4444 codec offers the utmost possible quality for 4:4:4 sources and for workflows involving alpha channels. It includes the following features:
Full-resolution, mastering-quality 4:4:4:4 RGBA color (an online-quality codec for editing and finishing 4:4:4 material, such as that originating from Sony HDCAM SR or digital cinema cameras such as RED ONE, Thomson Viper FilmStream, and Panavision Genesis cameras). The R, G, and B channels are lightly compressed, with an emphasis on being perceptually indistinguishable from the original material.
Lossless alpha channel with real-time playback
High-quality solution for storing and exchanging motion graphics and composites
For 4:4:4 sources, a data rate that is roughly 50 percent higher than the data rate of Apple ProRes 422 (HQ)
Direct encoding of, and decoding to, RGB pixel formats
Support for any resolution, including SD, HD, 2K, 4K, and other resolutions
A Gamma Correction setting in the codec’s advanced compression settings pane, which allows you to disable the 1.8 to 2.2 gamma adjustment that can occur if RGB material at 2.2 gamma is misinterpreted as 1.8. This setting is also available with the Apple ProRes 422 codec.
Apple ProRes 422 (HQ)
The Apple ProRes 422 (HQ) codec offers the utmost possible quality for 4:2:2 or 4:2:0 sources (without an alpha channel) and provides the following:
Target data rate of approximately 220 Mbps (1920 x 1080 at 60i)
Higher quality than Apple ProRes 422
Apple ProRes 422
The Apple ProRes 422 codec provides the following:
Target data rate of approximately 145 Mbps (1920 x 1080 at 60i)
Higher quality than Apple ProRes 422 (LT)
Apple ProRes 422 (LT)
The Apple ProRes 422 (LT) codec provides the following:
Roughly 70 percent of the data rate of Apple ProRes 422 (thus, smaller file sizes than Apple ProRes 422)
Higher quality than Apple ProRes 422 (Proxy)
Apple ProRes 422 (Proxy)
The Apple ProRes 422 (Proxy) codec is intended for use in offline workflows and provides the following:
Roughly 30 percent of the data rate of Apple ProRes 422
High-quality offline editing at the original frame size, frame rate, and aspect ratio
High-quality edit proxy for Final Cut Server
The Apple ProRes family of codecs provides these advantages:
Quality indistinguishable from that of the most pristine sources: Maintains superb quality even after multiple encoding/decoding generations.
Mastering-quality 4:4:4:4 RGBA: Provides a lossless alpha channel with real-time playback (Apple ProRes 4444 only). Mastering-quality 4:4:4 Y′CBCRcolor and 4:2:2 Y′CBCR color are also available.
The quality of uncompressed HD at data and storage rates lower than those of uncompressed SD: Provides real-time editing performance comparable to or better than that of any other HD codecs in Final Cut Pro.
Apple ProRes encoding at any frame size—SD, HD, 2K, 4K, or other: Apple ProRes codecs can also be encoded into nonstandard frame sizes, but nonstandard frame sizes are not supported for real-time playback in Final Cut Pro.
Variable bit rate (VBR) encoding: “Smart” encoding analyzes the image. Efficiency is increased because excess bits are not wasted on simple frames.
10-bit sample depth: Preserves subtle gradients of 10-bit sources (sunsets, graphics, and the like) with no visible banding artifacts. When you import a file using an Apple ProRes codec, you don’t have to first determine whether the file is an 8-bit or 10-bit file. Apple ProRes codecs always preserve the bit depth of your original source files.
I-frame–only (intraframe) encoding: Ensures consistent quality in every frame, with no artifacts from complex motion, and speeds up editing.
Fast encoding and decoding: Delivers high-quality, real-time playback and faster rendering times.
Equipment affordability: Because of low bit rates, you can edit more streams with more real-time effects on slower drives, or have more users accessing the same media over shared storage devices.
Workflow options for any video format that does not have native Final Cut Pro support: The Apple ProRes format provides an effective workflow for projects involving multiple acquisition formats when you want to standardize on a single codec.
Better rendering for native editing: Can be used to render long-GOP MPEG-2 formats (such as HDV and XDCAM HD) to speed up editing and avoid MPEG-2 reencoding artifacts before output.

Better Alpha channel handling

I've asked for this a lot: alpha channel saving with PS is terrible, and could use an update. And today, I was embarrassed by a bug that caused our game engine to perform poorly as a result of the way Photoshop handles the alpha channel.
The bug: make a 1024x1024 canvas, give it an opaque alpha channel (100% white, every pixel), then Image Size it down to something smaller, like 128x128. Now look at your alpha channel: grey pixels all along the border. ARRGGGHHH!!!1!1! It interpolated, I'm sure, using black alpha outside the canvas that doesn't actually exist, changing, in a powerful, fundamental way, the nature of the alpha channel. Video cards care about this stuff: 99.9% opaque is not 100% opaque. This is terrible.
The request: That PS intelligently offer better defaults when saving an image with an alpha. Right now, it offers, "What was the last bit depth you saved an image to?" Regardless of the fact that the previous image may have no relationship to the following image being saved, the default offering is always "what I did last time". This enables very easy pruning of alpha channels that should be there, or adding opaque alpha channels that shouldn't be there, bloating the file size.
I'd like PS to determine if an alpha channel is present, and base its default choice on that. If one is present, default to 32-bits. If an alpha channel si not present, default to 24-bits. That easy.
If multiple alpha channels are present, I'd like a dropdown menu to pick which one I want. Right now, if you save a PSD with multiple alpha channels to a 32-bit TGA, it throws all alpha channels away, and saves the image with a solidly opaque alpha channel, the choice no one asked for.
For texture work, or works where the graphics card is the destination, not the printed page, this cavalier handling of alpha channels is definitely not sustainable.
I'd love to never have to ask for this again.

Generally speaking the resize of an image on a layer in which the canvas is exactly the size of the data will result in transparency peeking in around the edge (i.e., I'm agreeing with you here, just using Photoshop terms). I've always thought this was kind of poorly thought-out too. As you say, the algorithm must default to using 0 vs., say, replicating (or "clamping") to the alpha of the pixels right on the edge.
I suppose theoretically, the thinking is that if you were to EXPAND the canvas, the area around the image would be transparent anyway, and a subsequent resampling would then have the same result as the above.
Knowing this, one way to work around the problem would be to create a slightly larger image, then Canvas Size it down to your intended resolution. That way there's layer data beyond the edges with which the resizing algorithm can work. I realize that's probably not a practical solution in general, but a trick to keep up your sleeve if you really do need that 128 x 128 image with alpha solid to the edge.
-Noel

ImageIO PNG Writing Slow With Alpha Channel

I'm writing a project that generates images with alpha channels, which I want to save in PNG format. Currently I'm using javax.ImageIO to do this, using statements such as:
ImageIO.write(image, "png", file);
I'm using JDK 1.5.0_06, on Windows XP.
The problem is that writing PNG files is very slow. It can take 9 or 10 seconds to write a 640x512 pixel image, ending up at around 300kb! I have read endless documentation and forum threads today, some of which detail similar problems. This would be an example:
[http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6215304|http://bugs.sun.com/bugdatabase/view_bug.do?bug_id=6215304]
This surely must be resolvable, but after much searching I've yet to find a solution. If it makes any difference, I ONLY want to write png image, and ONLY with an alpha channel (not ever without), in case there are optimisations that that makes possible.
If anyone can tell me how to address this problem, I'd be very grateful.
Many thanks, Robert Redwood.

This isn't a solution, but rather a refinement of the issue.
Some of the sources I was reading were implying that the long save time might be due to a CPU heavy conversion process that had to take place before the BufferedImage could be saved. I decided to investigate:
I loaded back in one of the (slowly) saved PNG images using ImageIO.read(file). Sure enough, the BufferedImage returned differed from the BufferedImage I had created. The biggest difference was the color model, which was DirectColorModel on the image I was generating, and was ComponentColorModel on the image I was loading back in.
So I decided to manually convert the image to be the same as how it seemed to end up anyway. I wrote the following code:
      * Takes a BufferedImage object, and if the color model is DirectColorModel,
      * converts it to be a ComponentColorModel suitable for fast PNG writing. If
      * the color model is any other color model than DirectColorModel, a
      * reference to the original image is simply returned.
      * @param source The source image.
      * @return The converted image.
     public static BufferedImage convertColorModelPNG(BufferedImage source)
          if (!(source.getColorModel() instanceof DirectColorModel))
               return source;
          ICC_Profile newProfile = ICC_Profile.getInstance(ColorSpace.CS_sRGB);
          ICC_ColorSpace newSpace = new ICC_ColorSpace(newProfile);
          ComponentColorModel newModel = new ComponentColorModel(newSpace, true, false, ComponentColorModel.TRANSLUCENT, DataBuffer.TYPE_BYTE);
          PixelInterleavedSampleModel newSampleModel = new PixelInterleavedSampleModel(DataBuffer.TYPE_BYTE, source.getWidth(), source.getHeight(), 4, source.getWidth() * 4, new int[] { 0, 1, 2, 3 });
          DataBufferByte newDataBuffer = new DataBufferByte(source.getWidth() * source.getHeight() * 4);
          ByteInterleavedRaster newRaster = new ByteInterleavedRaster(newSampleModel, newDataBuffer, new Point(0, 0));
          BufferedImage dest = new BufferedImage(newModel, newRaster, false, new Hashtable());
          int[] srcData = ((DataBufferInt)source.getRaster().getDataBuffer()).getData();
          byte[] destData = newDataBuffer.getData();
          int j = 0;
          byte argb = 0;
          for (int i = 0; i < srcData.length; i++)
               j = i * 4;
               argb = (byte)(srcData[i] >> 24);
               destData[j] = argb;
               destData[j + 1] = 0;
               destData[j + 2] = 0;
               destData[j + 3] = 0;
          //Graphics2D g2 = dest.createGraphics();
          //g2.drawImage(source, 0, 0, null);
          //g2.dispose();
          return dest;
     }My apologies if that doesn't display correctly in the post.
Basically, I create a BufferedImage the hard way, matching all the parameters of the image I get when I load in a PNG with alpha channel.
The last bit, (for simplicity), just makes sure I copy over the alpha channel of old image to the new image, and assumes the color was black. This doesn't make any real speed difference.
Now that runs lightning quick, but interestingly, see the bit I've commented out? The alternative to setting the ARGB values was to just draw the old image onto the new image. For a 640x512 image, this command (drawImage) took a whopping 36 SECONDS to complete! This may hint that the problem is to do with conversion.
Anyhow, I got rather excited. The conversion went quickly. Here's the rub though, the image took 9 seconds to save using ImageIO.write, just the same as if I had never converted it. :(
SOOOOOOOOOOOO... Why have I told you all this?
Well, I guess I think it narrows dow the problem, but eliminates some solutions (to save people suggesting them).
Bottom line, I still need to know why saving PNGs using ImageIO is so slow. Is there any other way to fix this, short of writing my own PNG writer, and indeed would THAT fix the issue?
For the record, I have a piece of C code that does this in well under a second, so it can't JUST be a case of 'too much number-crunching'.
I really would appreciate any help you can give on this. It's very frustrating.
Thanks again. Robert Redwood.

Printing swf error (no alpha channel?)

Hi,
I don't know if this has been covered before but I have tried the following:
Printing to PDF via the print menu from the swf
and
Printing to paper via the print menu from the swf
In both cases, the images that are on screen are PNGs created as a PNG sequence from After Effects. They contain alpha channels and the background of the swf is non-white. However the bounding box of the image gets printed as white, so I have a sequence of overlapping white regions, some of which occlude the image beneath. With alpha channels on the monitor, this is not apparent, but when on paper or in PDF format the occlusion is clear. I don't mind the white background; however I cannot deal with the occlusion. How can I solve this?
Sincerely,
-markerline

Eureka!! That works better than a vacuum cleaner. Only problem is I was using the AS3 reference and some of the PrintJob examples that were listed threw errors so I had to use the final example:
package
    import flash.printing.PrintJob;
    import flash.display.Sprite;
    public class BasicPrintExample extends Sprite
        var myPrintJob:PrintJob = new PrintJob();
        var mySprite:Sprite = new Sprite();
        mySprite.graphics.beginFill(0x336699);
    mySprite.graphics.drawCircle(100, 100, 50);
        public function BasicPrintExample()
            if (myPrintJob.start()) {
            try {
                myPrintJob.addPage(mySprite);
            catch(e:Error) {
                // handle error
            myPrintJob.send();
I did away with the package and the class and just called the function as a mouse event for a print-button. I'm not sure why the if(myPrintJob.start()) call works because nowhere am I declaring the print job to start. I guess that's something that happens automatically?

Alpha channel weirdness with hardware MPE

To begin, I'm using a GTX 480 with the hack, so I'm not going to complain too loudly it this is a result of using as-yet unsupported hardware. However, I just want to verify with other hardware MPE users (both legit and unsupported) if this issue is happening on other systems.
I've noticed some oddities with imported PSD files and the way that their alpha channels are rendered with hardware MPE, versus software MPE. I'm putting up a couple frame grabs with GPU acceleration turned on and off at couple different point where I'm using the PSDs. Forgive the PNG compression; you should be able to see the difference, nevertheless.
First up, 100% opaque text over a background. The edges of the text are... fuzzy, maybe?
Software:
Hardware:
Second, a couple layers Fast Blurring and fading in. The logo is 100% opaque, and there is a separate "glow" layer (rasterized in PS) behind it. Pretty obvious, here...
Software:
Hardware:
Finally, a mostly-transparent logo bug. The hardware version is not as transparent.
Software:
Hardware:
The only difference between each of these examples is that I turned on or off GPU acceleration in the Project Settings; it's the same PSD for each grab. I've also noticed that standard cross dissolves are a little chunky when dissolving to or from a graphic (even a flattened version); the opacity change is not as linear as it usually is. In software mode, this goes away.
Anyone witnessed similar results? Again, I want to believe that this is just a result of using the GTX 480 and the hack, without official support. It could very well be the nVidia driver, too, I suppose, but I haven't tried rolling back to check that (I'm running the latest versions).
Thoughts?

I can confirm this.
I do not think its the psd but the Alpha Channel in general.
The colours are off when in MPE (Nvidia GTX 285)
I filed a bug report.

Alpha channel distinction

Similar Messages

Maybe you are looking for