Digital juice alpha channels

im importing digital juice content with alpha channels, final cut is not recognizing the alpha channel. how can i fix that?

If I remember correctly, Digital Juice files are Animation codec with Alpha Channels and should key automatically. Highlight the animation in the browser and scroll sideways to the column marked Alpha, that will tell you how the file is being interpreted by FCP. If it reads None/Ignore then highlight the clip on your timeline and goto Modify>Alpha Type and choose Straight.
Alternatively, Digital Juice usually includes a matte with all their animations. Put the animation on V2 and the corresponding matte on V1, then right click the clip in V2 and choose Composite Mode> Travel Matte Luma. This will use the track on V1 as the alpha channel.
This works when the files have been compressed to a codec that doesnt support Alpha, but shouldnt be necessary if the files you are working with are indeed Animation codec with Millions+ (Alpha)

Similar Messages

Alpha channel issues

Greetings,
I'm trying to create a lower third using a still image that I created from a video clip using Quicktime Conversions. I then import it into FCP, drag it to a sequence and then add livetype text to it. In the preview mode on my main sequence when played is fine, but when I render it the alpha channel disappears and a black background replaces my video with the lower third material still there. What happened to my alpha channel? Is there a problem or a bug in FCP 5.1.1? I'm bewildered.
Thanks,
Jordan

Editmojo,
I exported just the text from Livetype. I'm trying to create a customized lower third, but everytime I render the lower third nested sequence after I have added it to the main sequence a black background takes over with the lower third media there. Ordinarily, when you follow the instructions that I did it automatically keys over the video behind it.What happened? I did not have this problem with FCP 4.5. Is there an issued with FCP 5.1? I just spoke to a tech at Digital Juice regarding the use of their animations and he said that there was an issue with FCP 5.1 when it came to alpha channels. Is that the case? Would the update solve the problem?
Thanks,
Jordan

Can't export alpha channel on a lower 3rd

I was able to sucessfuly change the font color of my live type.
I am intermediate to graphics and I was using the Digital Duice Editor's Took kit #10 - #239 lower third to use as a lower third while adding text in motion. I thought the alpha channel was built in. When I export in motion to .mov I get the lower third, my animated text, but a black background (no alpha to lay over the video) Slap me if this has been asked before, but I have tried a lot of things and still have the black background exported. Do I need to add the alpha overlay that comes with the lower third #239 in motion to make this a mask?
The Digital juice lower third works well in FCP and allows me to super impose it over video. Do I have to set up motion to have an alpha background before I impor the lower third?

I am intermediate to graphics and I was using the Digital Duice Editor's Took kit #10 - #239 lower third to use as a lower third while adding text in motion.< </div>
You are rendering out of Juicer 3? You have done in the past, going to FCP, and the alpha is intact? Then it must be your settings out of Juicer or you have not interpreted the alpha prperly in Motion. It might be straght or premultiplied, depending on your settings in Juicer.
Exporting out of Motion with alpha is easy if you know how to select the proper codec. It must be Animation (ther are other alpha-aware codecs but Animation is idiotproof).
Without watching over your shoulder, it's difficutl to tell whaich of the many beignner's mistakes you could be making. Once you figure it out, though, you wil lnever make them again.
bogiesan

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.

Unexpected Alpha channel behavior in Premiere

Is there no way to interpret alphas as straight versus premultiplied in Premiere? Why do my transparent layers and clips with alpha channels display differently with a Black Video layer below them?
Background info:
I'm exporting my film to files with codecs that support alpha channels, not because I want an alpha in the result but because I need full RGB / 444 color coding for digital cinema theaters. I'm using ProRes444, Targa and PNG Image sequences to preserve as much quality as possible in my master exports.
I've discovered that there is no option to disable the alpha transparency in the Export Media step while preserving at least 10 bits per color channel (Trillions of colors in AE).
To solve this problem, I've had to add a "Black Video" clip to the first video track, underneath the film's content. When this is done, the pre-rendered text elements with alphas look different. They are movie trailer style text treatments that are light text over pure black. (I'm on my ipad right now and don't see a way to upload screen shots to show examples)
The result with the black video layer applied at the bottom is similar to the way QuickTime 7 displays straight alphas incorrectly. This problem occurs with both straight and premultiplied renders. The rendered text is from after effects and is stored using the animation codec.
I'm aware of how to work around this, by maintaining the alpha transparency in Premiere and then removing the alpha channel of my export by running it through After Effects, but that is a ridiculous, time consuming step.
I'm working with the GPU Mercury Engine on with a K5000 from NVIDIA. Can anyone explain this behavior? Is there no way to interpret alphas as straight versus premultiplied in Premiere? Why do my transparent layers display differently with a Black Video layer below them?
Here are the screen shots
UNDESIRED EFFECT using Black Video layer at bottom: Notice the fuzzy glow surrounding the text. This is happening with both straight and premultiplied renders.
INTENDED LOOK when composited over nothing: The glowing edges are displayed the same way in Premiere as in After Effects.

In my understanding, the reason 444 is indicated is because they are not RGB codecs. They simply sample the same amount of color as is possible in true RGB codecs. They still require a conversion from RGB to YUV for coding to a file, which almost always introduces a very slight shift in values, though usually imperceptible or acceptable. If the codec is truly RGB there is no need to indicate luminance vs color sampling.
...I think.
Again thank you for your awesome input! You've been a huge help here on my day off. :)

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.

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.

Digital juice alpha channels

Similar Messages

Maybe you are looking for