Does anyone have a (good) reference for the mskHasAlpha masking value for ILBM? I'm struggling to find out what it means with regard to how the bitmap is stored and information seems to be somewhat scarce.
I understand it means that "the image has an alpha channel", but I'm looking for how it affects the encoding of the scanlines when storing as a file. Is it like mskHasMask in that it implies one or more interleaved scan lines (but I would assume a full 8 lines would make that RGBA and 32-bit not 24)? Does it denote the transparent "colour" somehow and, if so, why does that differ from mskHasTransparentColor? I'm hoping there's some kind of spec somewhere and it's just eluding me..
Thanks in advance.
First hit in Google: http://ftp.fau.de/aminet/docs/misc/ILBM64.readme
The note says that a 32bit ILBM should have mskHasAlpha set to indicate RGBA format.
Personally I would consider bmh_Depth = 24 + bmh_Masking = mskHasAlpha equal to bmh_Depth = 32 + bmh_Masking = mskHasAlpha or mskNone. In all three cases I'd expect the body to be encoded as 32 bitplanes RGBA.
Hi thomas,
I saw the ILBM64 doc and I just found it confusing (hence asking for a good source, or maybe I just need a new brain) as it says:
..so I didn't know whether something whacky was being done with that value; but then it continues to say:
Which, to me, seems to contradict itself - the mask planes are part of the image planes but files are not 32 planes deep? If there are 32 bit planes encoded, I'm not sure why was a new flag needed instead of just saying depth=32 and expecting RGBA (same as depth=24, RGB) because surely older programs that know about 24-bit will fall foul in decoding due to the extra planes are interleaved.
But anyway, can't change it now and you've confirmed what I was assuming so I'll continue down that path.
Thanks!
SignatureNotFoundException at line 1.
This is the problem with extending ILBM past its usefulness with impractical extensions. Things like 32 bit, ARGB and alpha masks are meaningless unless it uses dedicated chunks. But theyve forced chunky data into planar paridigms and it really doesn't fit. ARGB doesn't have depth, it has width, for one thing. The depth is, for all intensive purposes, only one plane deep for ARGB data. Depth also describes CLUT palette size but ARGB has no palette. And by the sounds of it they are stripping the bits of the ARGB data and grouping it into planes to store. It's a bit ridiculous given the pixels are not bitmapped and this would just slow down loading and saving. Now this doesn't help you to decode ILBM but I just think packing ARGB into an ILBM this way is a bit silly.
I agree. Using IFF ILBM to save chunky data is stupid and slow. There is IFF DEEP which can save chunky data as is.