Displaying a bitmap with alpha-support

[fabke]

Hi,

When creating a 32-bit bitmap with FDTDefineBitsLossless2
I have following problem:

- pixels with alpha == 0 are displayed correctly (i.e. fully transparent) only if the corresponding RGB-values are (0, 0, 0)
- pixels with alpha >0 and < 255 are displayed as if alpha were 255
-pixels with alpha == 255 are always displayed correctly (i.e. opaque)

Any suggestions?

[JAEzell]

How are you writing/producing the alpha data and the rest of the record?

--Jesse

[fabke]

Hi,

I'm working with 32-bit TARGA-files (made with Photoshop).. so I've all the necessary data.

First I change the order to ARGB, that's what flash needs apparently.

I use FDTDefineBitsLossless2 with format=5, no palette

It seems like flash only likes alpha==0 with RGB=(0,0,0).
As if the alpha-value is an indexed color.

For any other alpha-values (excluding 255).. it does not work: the RGB's are displayed as if there is no alpha at all.

[JAEzell]

Where did you get your information? (That it should be in ARGB, not RGBA)?

--Jesse

[fabke]

Trial and error...

That's the only wat to work with the provided SDK..
Now I discovered that alpha == 0 does work with other RGB's as well..

But what should I do when I have a bitmap with alpha between 0 and 255?
I use lossless compression.. maybe the JPEG-compression is the solution?

[JAEzell]

According to the MM docs, you should have color pallete data with all lossless compressed images. The color pallete size just changes depending on the number of colors. Color pallete data is always in the form of RGBA or RGB, never ARGB. I know this differs from the docs on openswf.org, but I trust the MM docs more because they are more recent.

--Jesse

[fabke]

I don't get it.. normally you use a pallete when working with 8-bit images. I's no use to have a pallete with 32-bit images.. besides my images are displayed correctly.

I think flash 4 only supports either full or no transparency in your input-image.

Ever worked with JPEG's in combination with an alpha-stream?

[JAEzell]

Palletes are included to save space...no matter what image format you are using, that is really the only reason to do it. That is why Lossless images work this way. All Lossless images contain 24 bit color values (rgb). Lossless2 images contain 24 bit color values, plus 8 bits of alpha data (RGBA). The number of colors actually used in a 24 bit image most likely isn't going to ever be 16 million. Usually, you will have a lot of repeated colors (for example, the background). By using a pallete, the background can be stored as a single character instead. I admit that for an image that uses more than 64k worth of colors, storing a pallete would be inefficient though...I am going to run some tests and see which set of docs is right. According to the guy that wrote the SWFScanner program (Jared Allen), the MM docs are pretty erroneous in this area. So there is still the possibility that pallete data is not stored for images with more than 8 bits...but I will have to check on this to confirm either way.

Flash 4 supports partial transparency in the alpha channels as far as I am aware.

The JPEG alpha data is tacked on to the stream, but it is just an array of alpha values instead of being put in with the image data.

--Jesse

[JAEzell]

Type 5 Lossless IS incorrect in the MM File Format Docs (what a suprise ;-). It is stored without a color table (and hence there is no color table length word) and then follows with DWORD values in the form of XRGB. 24 bit RGB files are often stored with 32 bit data for speed reasons (regardless of the useless byte added on). I am still working on the Alpha data, but I will get back when I figure that out for you. In any case, the alpha data doesn't appear to be in the X byte, because it is also there in the Lossless1 tag which doesn't support transparency...additionally, modifying the value makes no difference in the output.

For those interested in a code example, I will have an updated SWFSource SDK posted with an example of encoding a 24 bit TARGA file to SWF using the lossless tag before saturday morning (most likely, it will be posted friday night around 6 PST).

--Jesse

[JAEzell]

I have confirmed the format for 16 bit data.

16bit (format 4) is in the format of XRRRRRGGGGGBBBBB (no color table included or color table length written). Scan lines are all DWORD aligned.


--Jesse

[help578]

Hi,
I have noticed the same thing in that the alpha channel behaved as if it were 1 bit instead
of 8 bits and so acted only as a mask. Using the color transform with alpha does work
on the 32bit lossless bitmaps and so can be used to get various levels of transparency,
but as for per pixel levels I'm not sure. JPEGs separate 8bit alpha channels behaved the
same way I believe.

On a side note I've had no problem with large images but when
the image becomes very small, say 4x4, then the DefineBitsLossless fails to fill
the shape with the bitmap. Has anyone else seen this?
I use 32-bit alignment for scan lines, and compress the colortable with the data for
8bit bitmaps, but both 32-bit and 8-bit fail to fill at the small sizes.

Any info would be much appreciated.

[JAEzell]

Why do you need them that small? The simplest solution is proably just to have your code convert them from 4x4 to 16x16 (or some size that works) by tiling. It would probably display faster as well.

--Jesse

[fabke]

My final conclusions:

1. using 32-bit lossless bitmaps:
- the alpha channel behaves as if it were 1 bit instead (alpha-color = zero-index of the palette, mostly RGB=(0,0,0) if you don't have a palette)
- using the color transform with alpha works (if you rewrite
the PlaceObject2)

2. using JPEG-compression:
- alpha-mask behaves correctly
- color transform also works

cu

[help578]

As for small bitmaps I want my tool to take in what ever
size bitmap the user wants. I would like to know if others
have seen this problem to know if it is a file format discrepancy or just some strange bug in my system.
I can fix it by stretch blitting to a larger bitmap (rather
than tiling) and then decreasing the size by the same factor in the placeObj tag, but I would prefer to figure
out the file format.
Thanks

[Kuwan]

Originally posted by fabke
My final conclusions:

1. using 32-bit lossless bitmaps:
- the alpha channel behaves as if it were 1 bit instead (alpha-color = zero-index of the palette, mostly RGB=(0,0,0) if you don't have a palette)
- using the color transform with alpha works (if you rewrite
the PlaceObject2)

2. using JPEG-compression:
- alpha-mask behaves correctly
- color transform also works

cu

Could you please elaborate on your findings with 32-bit lossless bitmaps with an alpha channel. I've been implementing the DefineBitsLossless & DefineBitsLossless2 myself for a Java application and I haven't been able to get transparencies that look right with alpha values in DefineBitsLossless2. I would love to hear what you've found out about the alpha channel for 32-bit bitmap images. When I attempt this, the results tend to be rather messy, with the transparency working OK in some parts of the image, whilst being a terrible mess (colours come out wrong, loss of colour detail, etc.) in other places.

Thanks a ton for your help!

Dave

[fabke]

You should convert your 32-bit image into 2 streams: 1 JPEG-stream (24-bit), 1 alpha-stream (8bit)

Then use DefineBitsJPEG3..

[Kuwan]

Unfortunately we can't encode our bitmaps as JPEGs, we need lossless compression. Although it will probably suite our needs to use DefineBitsLossless and then do a color transform with alpha, but I haven't been able to figure out how you use the color transform with alpha yet. You mentioned that you could do it if you rewrite the PlaceObject2.

What did you need to rewrite for this? Do you have any examples that you might be able to share?

Again, thanks for the help! It gets so frustrating when Macromedia's SDK doesn't do what their documentation says it does.

[fabke]

you need to stream a ColorTransform With Alpha.. however, the placeobject-tag only supports colortransforms without alpha, so you'll have to write your own placeobject