[Ffmpeg-devel] Bug in img_convert

[Luca Abeni]

Hi Anders,

On Wed, 2006-08-30 at 13:20 +0200, Anders Moden wrote:
[...]
> yes. I was so eager that I didn't look up the right define. There  
> seemes to be some endian stuff in the defines that set ABGR or RGBA.  
> Why don't you name the format in byte order in memory ?
Michael explained this about 1 week ago; let's see if I got it right:
- PIX_FMT_RGB32 is endian-dependent and a single pixel is built as
	A << 24 | R << 16 | G << 8 | B
  (so, its "integer value" is 0xAARRGGBB)
- PIX_FMT_BGR32 is
	A << 24 | B << 16 | G << 8 | R
- PIX_FMT_RGB32_1 and PIX_FMT_BGR32_1 are like the previous one, but the
alpha byte is "after" the R, G, and B ones
- PIX_FMT_ARGB, PIX_FMT_ABGR, PIX_FMT_BGRA, and PIX_FMT_RGBA are
endian-independent, and indicate the order of the bytes in memory. So,
in PIX_FMT_ARGB a pixel is stored in memory as (first byte)B G R A(last
byte)

So, there are 4 "32 bit RGB" formats, and two ways of naming them (based
on the "integer representation" of a pixel, or based on memory order).

> > It has been added to libavutil only recently, and no conversion  
> > routines
> > for it exist yet.
> > Conversion from/to PIX_FMT_ABGR will be supported in a short time
> > through libswscale.
> 
> Great. I saw that libswscale was going LGPL.
Michael is relicensing the "non accelerated" code of libswscale as LGPL.
As soon as the "pixel format name" stuff is cleared out, I'll take care
of enabling the compilation of the non-MMX code when --enable-gpl is not
used.

> Does libswscale do a  
> better conversion without the interrim steps of rgb24 ? As it is now  
> there is a rgb24 image created before the rgb32 is created.
I did not try, but libswscale is known to work better (and with better
quality) than img_convert(), so I think the answer is "yes"

> >> When converting from rgb24 to abgr32 the img_convert routine ends up
> >> in creating interim images of rgb24 and end up in a endless loop.
> > This is obviously a bug; I'll look at it. Thanks for noticing and
> > reporting it.
> 
> ok. Thanx your self for talking to me. Lots of messages are never  
> answered here...
If it happens, it's not done on purpose... People are busy, and try to
answer when they find the time

> I have a "stretch" routine that enlarges a bitmap (x,y) RGB32 (long  
> word) to a (xp,yp) RGB32 bitmap where xp,yp is power of two. Could  
> this be of use in libswscale ?
I do not know the libswscale internals... But I think it is already
optimized for this special case


				Luca
-- 
_____________________________________________________________________________
Copy this in your signature, if you think it is important:
                               N O    W A R ! ! !