Alpha channel in HTML5 format

Hi all,
I use Captivate 7 Subscription Edition on Windows Home Premium 64bit , and
I have a problem with alpha channel and html5.
I often make projects importing videos with alpha channel   (transparent background).
When I decide to publish my   projects in Flash (SWF) all works smoothly without problems, but when I check the HTML format the alpha channel doesn't work anymore. In fact in the publishing process Captivate opens the Media Encoder to transform the videos from FLV to   H.264 (.MP4) format. When I go to see the SCORM in HTML5 the videos doesn't have anymore alpha channel and other times they neither don't show anything, just audio works...
I read on internet that the H.264 format doesn't support   alpha channel but I can't find any other solution to make it work in a captivate SCORM 1.2 in HTML5 format.
Can someone give me a workaround or a solution??
I need the HTML5 format to make our company projects work on   mobile devices (such as Ipad, Iphone, Android, etc).
Roberto.
P.S. I found this jquery library: https://code.google.com/p/jquery-seethru/ the problem is that I can't make it work with the SCORM and   don't know if it really can work...

You've found the answer - h.264 doesn't support alpha channels (which I find a bit silly).
So the only real option you then have is .FLV...but if you need to deliver to mobile, then FLV won't work...
So then seems like your only option is to layer in the background within the video, export that as .MP4/h.264, then bring that in to the CP project and match it up as best you can with the rest of the background.
-E

Similar Messages

How to retrieve alpha channel data in format plugin

I want to ask how to get the alpha channel 's data that describle the document's transparent info, in a format plugin.
for example , when open a PNG file in Photoshop, the photoshop set FormatRecord:: planes to 3 (not 4),
in this case i can only request the RGB data.
then how can i get if the pixel is transparent in document ? (that is 0 - completely transparent, 255 - completely opaque)
Thanks~

i have resolved this problem, it's maybe i didnot set the fmtCanWriteTransparency flag in the pipl.
thanks.

Alpha Channel Help

Hi
I was wondering how did they get this alpha channel, is there a tutorial any one knows or just what technich its called cause i cant find a thing how they did it
http://hotfile.com/dl/57865326/b1bed5b/ShockBall.dds.html
I cant upload the image here or from imageshack as its in dds format, and changing its format it looses it alpha channel, i desperatly seek help to resolve this and really appreciate any kind of help

Generally speaking, you manage transparency in Photoshop by using a layer to contain your image elements, and either making the background invisible or deleting it.
There are a variety of ways to make parts of your image transparent. For example, you can use a layer mask to "hide" parts of it, or you can simply "delete" through parts of it. Photoshop will show you a "checkerboard" pattern through the transparent parts of your image, as shown here.
I'm not familiar with the .dds format, and I don't think Photoshop can save that format, but you can save an image such as this one with transparency (alpha channel) in a format such as Portable Network Graphics (.png), or Compuserve GIF (.gif). A quick search of the web turns up a number of converters claiming to be able to convert .png to .dds.
If you'd like to test with it, the above image, saved as a .png with transparency, can be found here:
http://images.prodigitalsoftware.com/Ball.png
-Noel

How to set alpha channel names in a format plugin?

I am writing a format plugin with 6 color planes for CMYK mode. I want to set the apha channel names for planes 5 and 6 to "White" and "Clear" instead of "Alpha 1" and "Alpha 2" when I read the color data from my file. How do I set the alpha channel names?
Thanks!

I am still trying to find a solution to this. The propChannelName is read only and the documentInfo structure is NULL when reading. Any suggestions?

Alpha channel data with layered format plugin

I have a layered format plugin and I am trying to write the alpha channel information separately. I have set up channelPortProcs and I am attempting to read the pixel data with readPixelsProc. The issue is that even though the readPixelsProc function doesn't return any errors the rectangle that is supposed to store the rectangle that was actually read is a 0x0 rectangle. I can't seem to find why this would be or what I might be doing wrong. Here's what I have so far:
// set up the pixel buffer
int32 bufferSize = imSize.h*imSize.v;
Ptr pixelData = sPSBuffer->New( &bufferSize, bufferSize );
if (pixelData == NULL)
     *gResult = memFullErr;
     return;
// Define the source and destination rectangles
ReadChannelDesc *alphaChannel = gFormatRecord->documentInfo->alphaChannels;
PIChannelPort port = alphaChannel->port;
PSScaling scale;
scale.sourceRect = scale.destinationRect = alphaChannel->bounds;
VRect destRect = scale.sourceRect;
// Set up the descriptor for reading pixel data
VRect wroteRect = {0};
PixelMemoryDesc dest = {0};
dest.rowBits = imSize.h*alphaChannel->depth;
dest.colBits = alphaChannel->depth;
dest.depth = alphaChannel->depth;
dest.data = pixelData;
// Put the pixel data into the buffer
*gResult = gFormatRecord->channelPortProcs->readPixelsProc(port,&scale, &destRect, &dest, &wroteRect);
if(*gResult != noErr)
     return;
The alpha channel gives me the proper name, but I just can't get the data associated with it. Thanks.

I am still trying to find a solution to this. The propChannelName is read only and the documentInfo structure is NULL when reading. Any suggestions?

After-Effects to FCP - Best format to use to export clip with alpha channel ?

Hello All;
I have created a 10 second video in After-Effects that I want to use in FCP. It seems that I am unable to render out to a Quicktime movie with both the video and the alpha channel (I can only render to one or the other). Could you tell me the best method to get a short video from AE to FCP ? What is the best format to use in AE ? Thanks.
Tim

Animation codec with colors set to Millions +. The plus is your Alpha channel.
If you have FCS 2009 you can also export to Pro Res 4444.

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.

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

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?

.mov files with alpha channels won't import on Adobe Premiere Pro CC

Just FYI, Apple:
This issue with Quicktime not seeing .mov files in Finder (or I should say, not playing them) is a HUGE problem for anyone who edits video.
If you export a file as .mov in After Effects, and have any transparency (RGB+Alpha channels), there is no way to import them into current projects. None.
PLEASE fix this, as I quite enjoy my job, and don't feel like losing it because my client doesn't understand why they can't have lower thirds in their video I'm contracted to do (and subsequently fires me and finds someone on a Windows rig).
Thanks.

What is up!
Based on my tests, it appears that the Mavericks embedded QT structure no longer considers many of the legacy compression formats to be supported under Mavericks. These formats were, by default, turned off under Lion and Mountain Lion which may indicate that Apple intends to drop even passive native support sometime in the future. Files containing Animation or PNG compressed data are no longer QL compatible and now force automatic QT X v10.3 conversion as mentioned above. Even worse, it appears other commonly used fomats like DV/DV in DV and AIC/PCM in MOV are also being relegated to this group. Luckily, DV/PCM in MOV, HDV/PCM in MOV, and ProRes422/PCM in MOV, along with all of my H.264/AAC/AC3/Chapter M4V distribution/iTunes managed files remain fully compatible with both QL and QT X v10.3 under Maverisks. This last is significant for me since many files containing AC3 as the primary audio stream are no longer QL/QT X v10.3 compatible with certain file extensions and/or container types which now appear to be checked in specific situations. Unfortunatly, what we've seen and learned thus far seems to be just the "tip of the iceberge."

Importing .bmp with alpha channel

Is there a difference between the way that the Windows and
Mac versions of Flash 8 Pro handle alpha channels on .bmp files? We
are working with a .fla that was created in the Windows version of
Flash 8, but we are editing it with the Mac version. When we import
the .bmp files that we made on our Mac, the alpha channels don't
show up. But the same .bmp files that were imported with the
Windows version do display their alpha channels. We had to change
the format to .tif in order to avoid "losing" the alpha channel.
Can anyone shed any light on this? Thanks!

Use PNG-24.
Chris Georgenes
Animator
http://www.mudbubble.com
http://www.keyframer.com
Adobe Community Expert
*\^^/*
(OO)
<---->
masterys wrote:
> Is there a difference between the way that the Windows
and Mac versions of
> Flash 8 Pro handle alpha channels on .bmp files? We are
working with a .fla
> that was created in the Windows version of Flash 8, but
we are editing it with
> the Mac version. When we import the .bmp files that we
made on our Mac, the
> alpha channels don't show up. But the same .bmp files
that were imported with
> the Windows version do display their alpha channels. We
had to change the
> format to .tif in order to avoid "losing" the alpha
channel. Can anyone shed
> any light on this? Thanks!
>

InDesign CS5 will not import Alpha Channels from images saved in Photoshop CS6

Just searched through the forums to find this thread in the (now-Read Only) Photoshop CS6 Beta forum:
http://forums.adobe.com/message/4310886
Which is exactly the same issue I'm having. I just cropped about a 1000 images with alphas originally created in PS5 and resaved using PS6.
My client still uses CS5 and the images won't recognize the alpha channels in inDesign5.
I see in this thread that it said a fix for older versions of inDesign was being worked on, this was back in April.
Any news on these fixes? (before I open PS5 and resave all these files)

Hi Peter,
The images in question all use alpha channels to mask out the image backgrounds (usually white) in InDesign layouts.
I opened the images in PS6 to crop out excess background (to get file size down) and saved the new files.
When I go to import the images one by one into InDesign 5 (via Cmd-D, Import options ticked) the Alpha Channel pull down menu is greyed out and I'm unable to select the Alpha Channel.
If I open the image in PS5 and resave, I'm then able to access the Alpha channels in ID5... but that's a lot of images to go back through to fix.
I also tried opening the layout in ID6 (where the alpha channels do work) and saving down to the idml format. When opening up in ID5 the alpha channel is no longer recognized and the background of the image that was masked out is now visible.
Cheers,
Alan

Alpha channel in HTML5 format

Similar Messages

Maybe you are looking for