Re: [libdc1394-devel] Next issue in libdc1394

[Damien D. <da...@do...>]

On Tue, 2006-11-21 at 08:50 +0100, Georg Glock wrote:
> Hi,
> 
> some time ago I remarked a problem with the 16 bit raw-image functions.
> 
> Now I found some time to dig a bit deeper...
> 
> The function 'dc1394_bayer_decoding_16bit()' is declared in
> 'conversions.h' as follows (both extracted from the most recent SVN-files):
> 
> dc1394error_t dc1394_bayer_decoding_16bit(const uint16_t *bayer, 
> uint16_t *rgb,
>     uint32_t width, uint32_t height, dc1394color_filter_t tile,
>     dc1394bayer_method_t, uint32_t bits);
> 
> but implemented in 'bayer.c' this way:
> 
> dc1394error_t
> dc1394_bayer_decoding_16bit(const uint16_t *restrict bayer, uint16_t 
> *restrict rgb,
>     uint32_t sx, uint32_t sy, uint32_t tile,
>     uint32_t bits, uint32_t method)
> {
> ...
> }
> 
> You see the error?
> It's the position of the 'bits' and 'method' parameter!
> Which one is correct?
> I suspect the declaration was the initial intention (i.e. to put the 
> 'bits' parameter last).
> One thing I do not really see is the necessity of that parameter.
> When I'm not wrong it's only used as a parameter to a 'CLIP16()' 
> function from within
> some 16-bit-conversion-functions - i.e. it's only used in 16 bit 
> routines in any case.
> Wouldn't it be better to use maybe a constant in the above mentioned 
> 'CLIP16()'
> function?
> Or did I missed some other reason of that parameter?
> 
> Btw., declaring a function with different type-names than using in the 
> implementation
> (e.g. 'dc1394color_filter_t tile' in the header compared to 'uint32_t 
> tile' in the '.c'-file - see
> above) looks not that professional... ;-).

Ugh. All this is very messy indeed. It will be fixed in SVN 330.

Thanks! :-)

Damien

-- 
  _    Damien 高原 Douxchamps, PhD
 ('-   Post-doctoral investigator
 //\   Image Processing Group, NAIST
 V_/_  http://damien.douxchamps.net/