2 Replies Latest reply on Oct 17, 2008 11:47 AM by Rothrock

    DefineBitsJPEG3 ‘Alpha’ Issue

      We are currently in the process of writing our own .swf files from an automated server process. This process takes groups of .PNG files and assembles them together using C#.NET and produces a movieclip which we eventually send to the Flash Player (Flash Player 9+).

      This process works only under certain conditions, and we are confounded as to why we cannot get a process like this to produce a consistent .SWF that is interpreted correctly by the Flash Player.

      The problem is, under certain conditions the Flash player loses all association with the PNG ALPHA data present within the images and we get a BLACK BOX around SOME of our images that have been run through this process. This essentially leads to unusable movieclips because we get a black box flashing all throughout the playback of the movie clip.

      After many man-hours of research, we believe this issue has to do with the ZLIP COMPRESSED ALPHA ARRAY that makes up a portion of the DefineBitsJPEG3 SWF tag. The Flash Player seems to lose association with the ALPHA data when this ZLIB COMPRESSED array nears the 4000 byte mark. If the ZLIB COMPRESSED array stays below the 4000 byte (ish) mark, the alpha data is interpreted correctly. If the ZLIP COMPRESSED array goes near and beyond 4000 bytes, we lose the alpha channel interpretation and we get black boxes.

      The DefineBitsJPEG3 SWF tag is made up of two distinct data blocks. The first block is the actual JPEG image data. The second data block consists of a ZLIB COMPRESSED array that contains the image’s ALPHA data only. We have performed the following analysis on this data:

      1) We have tried using a minimum of at least 5 different commercial and open-source based zlib compression libraries. Each compression library produces a compression result that is DIFFERENT FROM THE ONE FLASH USES when compressing this data (using the import function) in the Flash IDE. According to Adobe’s documentation, there is nothing in it to lead us to believe that Adobe is using a ‘customized’ or ‘different’ zlib algorithm that differs between industry-standard based libraries that are readily available. None the less, the compression results from the ‘Flash IDE/Abobe import’ are different than anything we’ve been able to produce using any one of the other libraries.

      2) Importing the same set of images using the Flash IDE produces consistently good results, every time. When the Flash IDE imports the images, all of the PNG files get converted ‘properly’ and we do not get any black boxes. We have compared and analyzed the resulting compressed alpha data between what the Flash IDE is doing and the commercial libraries and we cannot figure out what the Flash IDE is doing differently in it’s ZLIB compression process.

      We are adamant in our pursuit towards the resolution of this problem because:

      1) We have a production requirement of creating thousands if not tens of thousands of .SWF file movieclips within an automated server situation. Interjecting the Flash IDE into a production pipeline of this nature, as a solution to properly produce correctly functioning movieclips, is not viable for us in terms of speed, licensing costs, and other factors.

      Going forward, we are going to try the following:

      1) Interjecting Adobe AIR into the process to test out the ZLIB COMPRESSION that is included within this framework. Adobe AIR provides access to the filesystem as well as a BYTE ARRAY COMPRESSION command that we think may be the same algorithm as the one the Flash IDE uses. We are not sure of how this will pan out, and even if it does work, we would prefer not to have to interject Adobe AIR into our production process, just to ZLIB Compress an alpha array and hundreds of thousands of images.

      We are also certainly open to the fact that the issue with the Flash Player losing the alpha data MAY NOT be due to the ZLIB COMPRESSED alpha data array. If we can gain additional insight into the cause of the problem we will certainly implement a solution to address the true source of the problem. After many man-hours researching this behavior, we have tried to find some kind of consistent observation that may be causing the alpha channel loss, and the ZLIB COMPRESSION seems to be a logical suspect as the cause of the issue.

      Thanks in advance to anyone who can help us out!!!!!!
        • 1. Re: DefineBitsJPEG3 ‘Alpha’ Issue
          clbeech Level 3
          although it's obvious that the level of sophistication that you and your team are well beyond my expertise, I have one stupidly simple question - have you tried using the cacheAsBitmap property on the imported clip?
          • 2. Re: DefineBitsJPEG3 ‘Alpha’ Issue
            Rothrock Level 5
            Under older versions of Flash Player there was a hard coded array that held the items with alpha transperency that needed to be anti-aliased. After 10 items went into that array the alpha channel was ignored on subsequent clips.

            The solution back then was have fewer than 10 items or set _quality="LOW" which avoided the anti-aliasing and kept all transperencies.

            My understanding was that with Flash 8 or 9 player (I can't remember) I had heard that this had been addressed, but that they had not made it infinate, just that they had expanded the memory allowed for that array.

            So if you can set _quality="LOW" and the problem goes away...well then I'm guessing that is what is causing it. Of course _quality="LOW" will make your playback look like crap. But just try it in order to diagnose the problem.

            Other than that I'm guessing you can use bitmap data class to compose all the content before you show it to the stage?