Re: Question concerning MNG alpha support using DHDR delta_type 1.

Hi,

(cc'ing as it's unclear if you are a mng-list member)

> I'm fairly new to the MNG format.  I have encountered a problem with
> creating a movie using alpha channels.   I apologize if this is the
> wrong place to go for an answer. If anyone wants more detail than I'm
> about to list, please send an email.

Let's confine the discussion to mng-list, as that's the main forum, and 
especially in this case as the 'problems' you describe are actually 'by design' 
as specified in the MNG docs.
 
> Simply stated, I have a 512x512, 32 bit (uncompressed in rgba format),
> 60 frame mng file.  The movie should fade in and the fade out using the
> dhdr for frame deltas. I'm using libmng to decompress this file.  The
> alpha channel is correct when the image "fades in", but the color never
> fade back out.

Yes. You can't really 'fade out' in the way that you are expecting here. 
What's painted on the canvas can't be undone other than by 'restoring' the 
background. So fading in is ok, as long as each step is added with a fairly 
high transparency. Others may be able to explain that in much better detail 
than me...

>  According to the libmng author's comments (I'm amazed at
> how well commented his source is!), 

<blush>ahhh...urrrmmm....</blush>

> he cites that he is using alpha
> blending for the composite.  My first question is why does the library
> blend the alpha channels instead of simply applying the alpha deltas???

libmng adheres to the spec that defines the behaviour in this way.
 
> The image is encoded with dhdr chunks.  The delta_type is 1.  The MNG
> spec lists this as "Block pixel addition, by samples, mod
> 2^sample_depth".  "By samples", if I am interpreting it correctly,
> indicates that each color is done independantly of the others.  So, the
> alpha should be differenced relative only to the previous alpha, right?
> This is what I'm assuming based on the png spec which makes it clear
> that filters are applied to a byte, regardless of the format of the
> data. Also, the description for "alpha addition" (type 2) states that
> "the color samples are not changed".  Using alpha blending for pixel
> addition (type 1), the alpha value alters the color value if blending is
> applied, which seems inconsistent.

Uhmmm, not exactly. The delta operation is performed in memory, before it is 
displayed on the canvas. You should be able to 'fade-in'/'fade-out' on a delta-
image, but to get the same result 'on screen' you would need a framing_mode 
to explicitly restore the background for each frame.
 
> There is an inconsistency with what libmng appears to be doing and what
> I'm doing. Can someone please clarify this for me?  I think I'm
> misintepreting the spec.  I'm not trying to place blame on any party, I
> just want this movie working :(

See above.
 
> Aside from using two seperate dhdr chunks, one to represent the delta of
> the image (delta_type = 3), and one to replace the alpha (block_type =
> 5), is there a way to take a strict byte difference using delta-png?  To
> me, it seems like storing the alpha channels as replacement will make
> the compression worse.  I'm not sure if that is the correct answer.

Mmm. Not entirely sure what you mean here. But, if you want to fade an 
image in, take the base image, fully transparent, then keep adding the same 
alpha-delta to decrease the transparency in equal steps. Again make sure to 
display each frame with a restored background. This way it should return 
what you are expecting. To fade-out, keep subtracting the same alpha-values 
and again paint against a restored background and your image will fade out.
Since the alpha-channel deltas all contain the same value they should 
compress very well, and if you make both operations happen inside a LOOP-
ENDL you basically only need a 'fade-in' alpha-delta and a 'fade-out' alpha 
delta. So you shouldn't require much more space than the original image itself.

(ps. If you want to keep something else in the background, try using the image 
property of the BACK chunk)

(pps. MNG is not exactly designed for video usage! MPEG may suite your 
needs better)

Gerard


--
Send the message body "help" to [email protected]