Re: Report on time needed for completing v4l Bayer interpolation.

[Hans de Goede <j.w.r.degoede@hhs.nl>]

kilgota@banach.math.auburn.edu wrote:
> 
> Hans,
> 
> I made your Bayer code to work. It was not terribly difficult, but did 
> need a bit of fixing and fooling.
> 
> So now the gp_bayer_decode function (in byr2ppm.c)says
> 
> int
> gp_bayer_decode (unsigned char *input, int w, int h, unsigned char *output,
>                  BayerTile tile)
> {
> //      gp_bayer_expand (input, w, h, output, tile);
> //      gp_bayer_interpolate (output, w, h, tile);
>         clock_t time_start=clock();
>                 fprintf(stderr, "Starting bayer v4l-interpolation\n");
> 
> 
> 
> v4lconvert_bayer_to_rgb24(input,
>  output, w, h, tile);
> 
>         clock_t time_end=clock();
>         fprintf(stderr,"Total time of v4l Bayer :\t%i ms\n",
>                                     (int)(time_end-time_start)/1000);
> 
> 
>         return (0);
> }
> 
> and the result for the same photo as before is
> 
> Total time of v4l Bayer :       0 ms
> 
> In other words, the time is reduced by a factor of approximately ten 
> from the code in the original libgphoto2/bayer.c (the straight bilinear 
> version).
> 

Well 10x might be a bit exaggerating, see my comments about clock() precision 
below.

> With a larger 640x480 image the time required is variously 0 ms or 
> sometimes 10 ms, so again a dramatic improvement.
> 

Hmm, if it jumps between 0 and 10 then clock() apparently has a 10 ms 
resolution I know the resolution of clock() wasn't all that great, but this is 
kinda bad actually.

> What would you suggest to do in order to get a more meaningful 
> measurement, at this point? Remove the dividend 1000 completely?
> 

That wont help, I advice you to use gettimeofday instead that much much better 
precision (sub microsecond on most systems).


> As far as the output image is concerned, the results are as I would 
> expect, though. To me, the output appears to be pretty much identical to 
> what the unmodified bilinear interpolation gives, which was in the 
> "original" libgphoto2/bayer.c. That is, there is lots of zipper effect 
> or ladder effect which is visible at vertical and horizontal edges all 
> over the photo, and this artifacting can be easily seen even at the 
> original 320x240 resolution without doing any magnification.
> 

Ack.

> Incidentally, the photo is the "infamous number 23" and you can see the 
> same photo on the website, as 023.ppm (now that I got the permissions 
> problem fixed). In the paper there are also some magnified views of a 
> small portion of the same photo, which show the effects of the three 
> different algorithms that show up especially at the edges of the balcony 
> railing and at the tops of the buildings in the distance.
> 
> Bottom line: I will see if I can figure out anything to get rid of the 
> zippering without excessively jacking up the time needed. Probably the 
> first thing to test is the accrue functionality, or a modification of that.

Ok and Thanks!

Regards,

Hans

--
video4linux-list mailing list
Unsubscribe mailto:video4linux-list-request@redhat.com?subject=unsubscribe
https://www.redhat.com/mailman/listinfo/video4linux-list