[Ffmpeg-devel] PIX_FMT_RGB555 and alpha channel

[Steven Johnson]

Michael Niedermayer wrote:
> Hi
>
> On Fri, Oct 20, 2006 at 10:12:35PM +1100, Steven Johnson wrote:
>   
>> Hi,
>>
>> Michael Niedermayer wrote:
>>     
>>> Hi
>>>
>>> On Thu, Oct 19, 2006 at 02:02:34AM +0200, Alex Beregszaszi wrote:
>>>  
>>>       
>>>> Hi,
>>>>
>>>> Current FFmpeg uses the MSB of RGB555 as alpha channel. Look at
>>>> pix_fmt_info in imgconvert.c. This causes it to set the MSB in case of
>>>> conversion to RGB555.
>>>>
>>>> Is that for a reason? 
>>>>    
>>>>         
>>> i dont know :)
>>>
>>>
>>>  
>>>       
>>>> I would propose adding RGBA555 for the alpha
>>>> channel containing format and remove the alpha channel from RGB555.
>>>>
>>>> Any objections?
>>>>    
>>>>         
>>> could you elaborate on why the alpha channel bit is a problem?
>>>
>>> [...]
>>>  
>>>       
>> I will elaborate.  Alex and I are implementing FLC/FLX and DTA encoding 
>> into ffmpeg.  We are a little way from having stuff ready to submit, but 
>> there is a problem with compression when the Alpha bit is set in an 
>> RGB555 pixel, for the FLX format.  It means we have to mask every pixel 
>> coming in, to take the spurious alpha bit out, or that bit prevents run 
>> length compression from being effective.  The format is really wanting 
>> to use RGB555, without alpha, so that black is 0x0000 and not 0x8000 but 
>>     
>
> why does RLE compression not work with the alpha bit set?
> and why exactly is the alpha bit set at all? if imgconvert.c sets it, IMO
> fix imgconvert.c so it doesnt
>   
Because the FLX format stupidly makes runs of bytes, not pixels. 
therefore 0x80, 0x00, 0x80, 0x00 is uncompressable whereas 0x00, 0x00, 
0x00, 0x00 is.

>
>   
>> the only option in FFMPEG is RGB1555.  So the options are add a true 
>> RGB555 and change the existing RGB555 to an RGBA555, or for us to mask 
>> every pixel when it is using RGB555 pixels.  We currently mask, but it 
>> makes the code ugly, and it looks like a hack, and it will be slower 
>> than if there was a non-alpha version of RGB555 available to use.
>>     
>
> a bitwise and per pixel isnt much and i will not accept adding an additional
> pixel format to avoid the 1% speed loss it causes (for a dead format)
> additionally, 
Agreed, I was just elaborating on why the question was asked.  I don't 
think it is a big issue and is pretty easy to deal with, as you say.  In 
fact we have already dealt with it by masking.  I think it just made 
Alex look into why the bit was set, which prompted his question, but I 
can't speak for Alex. 

(I am not pressing this point, cause I don't really care either way, but 
an alternative would be to just invert the Alpha State in FFMPEG for 
this pixel format, 0 meaning opaque and 1 meaning transparent, at least 
then pixel data would normally be what one expects for an RGB555 Format 
unless there was Alpha in the source which I would guess is not that 
common.)
> IMHO a 15/16bpp RLE-RGB encoder makes only sense if you also
> have a pretty smart algorithm to choose the color, lossless will be to
> big to be worth it (=gzip/bzip of raw will be smaller)
>   
Also agreed, it isn't a very efficient format.  But it is simple and 
extremely fast on slow processors.   Other types of encoding could do 
better, for sure, but as you say it is an ancient format (not quite dead 
but not breathing very much either :).
> so id suggest you implement a viterbi based rate distortion optimal encoder
> this should be fairly easy for such a simple format
> if you do you wont notice the difference in speed that single and has :)
>   
Ill talk to Alex about this, thanks.
> [...]
>