Alpha Channel/Border

When I place an object on an alpha channel, save, and then import into Final Cut, the object has a grey border. How do I remove this?

Maybe I misinterpret you, but look here: http://discussions.apple.com/thread.jspa?messageID=3438756&#3438756

Similar Messages

  • 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

  • Are Quicktimes with alpha channel gone in Keynote 6.0?

    Say it aint so. This is a very crucial feature of the app for my company.

    While presenting from an iOS device is certainly useful, I want to be able to do the best presentations possible. Looks like Keynote 5.3 will be the tool of choice for some time yet.
    Keynote 6, while a step forward for maybe 99% of users (that don't want to care about what works and what doesn't on various platforms), is a major leap backwards for the professional presentation business.
    Time for Apple - or perhaps better yet, some third party - to make a Keynote Pro and make it desktop only, if that's what it takes. Bring back the larger choice of transitions, support for QuickTime alpha channels and dynamic Quartz Compositions, interaction with master slide objects and mixing of themes in the same presentation. And don't stop there:
    Add parallell layers or tracks, so that some visuals or audio can play uninteruppted over several slides.
    Add dynamic inputs, so a text and media fields can be populated by tweets or other RSS feeds.
    Add a proper theme editor, so you easily can change various defaults and maybe add custom border styles and stuff.
    Make the presenter's display more flexible, and allow for (simple) editing of slides while running the show.
    Phil Schiller may have the time and resources to let 3D animators render full frame wow!-inducing movies-as-transitions, but isn't it better to have more power within the application itself? And with Keynote 6, some of that power is gone.
    Maybe it'll be like with FCP X, where some of the lost features of the previous version got added back in an update. But as with anything Apple, who knows?

  • The odd tale of Quickmask and the alpha channel

    I'm posting this in hope rather than expectation - as I keep requesting this is fixed, but I seem to be a lone voice.
    I understand that this code was written back in the 90's - and I get the impression (from a senior Photoshop engineer no less) that no one really understands it...
    The odd tale of Quickmask and the alpha channel
    Try this:
    With Quickmask set to it's defaults (double click the quickmask icon and ensure it's set to 'colour indicates : masked areas'), paint in black to create a 'red' quickmask area. Hit Q to return to the selection border. You should see two selection borders - one at the edge of the image defining the outer edge of the selected area, and one defining the inner edge of the masked area that you painted.
    Now hit the 'save selection as channel' button at the bottom of the channel palette to create an alpha channel.Everything's as expected - the alpha is black ('unselected') where you painted.
    Now repeat the process, but with the Quickmask mode set to 'colour indicates : selected areas'.
    In this case where you paint in QM mode should be selected. Paint a patch and hit the Q key - it is. You have a single selected area. Now hit the 'save selection as channel' button at the bottom of the channel palette to create another alpha channel.
    This time the alpha is incorrect - it's the inverse of what it should be.
    And it gets worse:
    Ctrl / Cmd click on the alpha thumbnail to load the alpha as a selection -
    notice that it even loads the black area as a selection.
    It's been like this as long as I can remember... and I really wish it was fixed.
    I'm a Photoshop ACI. QM is a tool I'd like to get my students to use more, but this behaviour makes it 'difficult' to teach Quickmask to users, particularly in conjunction with alpha channels. In my experience it seems that most users find it more natural to 'paint on' a selection, rather than than 'paint off' a mask.
    So most users would prefer to set 'colour indicates : selected areas'
    I've been around long enough to know the rubylith heritage upon which Quickmask is modelled, however I now think it's time that baggage was left behind. I wonder what proportion of current Photoshop users even know what rubylith was?
    There are two points here:
    1. There should be NO connection between the QM paint state and the subsequent creation (or loading) of an alpha channel.
    Whether you choose to label it  a feature or a bug, it's clearly wrong to toggle out of QM mode, see a selection on screen, make an alpha channel - and find your alpha is reversed.
    And in addition to that - it's a 'freak' alpha that subsequently loads reversed...
    2. I think it's time to drop the rubylith baggage and set the QM paint mode to a default of set 'colour indicates : selected areas'.

    Charles,
    Thanks to your replies I've now discovered another twist to this tale...
    When I'm saving a selection, I typically use the 'save selection as alpha' button in the channels panel. That shows the issue I'm referring to.
    However, I've just discovered - thanks to your comments - that if instead you use the 'Select > Save selection' menu command you get a 'correct' alpha.
    If you care to try that second example again you'll find you can get two different alpha's from the same selection - depending upon which saving option you choose!
    This is now getting so complex, I'll have to put a pdf together explaining it and send it to our fiends at Adobe.

  • 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.

  • 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?

Maybe you are looking for