0 Replies Latest reply on Oct 17, 2008 8:46 AM by fgauer1

    DefineBitsJPEG3 ‘Alpha’ Issue

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