update: i fixed it myself with a couple of hours of trial and error; i think
you guys might be interested in the result. i would warrant this is the
simplest possible way to access the camera and save an image. it uses PGM
format, which is probably the simplest widespread image format.
// WORKS
// w/ WIDTH=960, HEIGHT=720
// or WIDTH=640, HEIGHT=480
// or WIDTH=320, HEIGHT=240
// WORKS
// w/ WIDTH=960, HEIGHT=720
// or WIDTH=640, HEIGHT=480
// or WIDTH=320, HEIGHT=240
static void
process_image (const void * p)
{
FILE *out = fopen("out.pgm", "w");
fprintf(out,"P2\n");
fprintf(out,"#CREATOR: ggp\n");
fprintf(out,"%u %u\n",WIDTH,HEIGHT);
fprintf(out,"255\n");
int x;
int y;
unsigned char * pixel = p;
for(y=0; y<HEIGHT; y++)
{
for(x=0; x<WIDTH; x++)
{
fprintf(out,"%u ",pixel[(y*WIDTH+x)*2]);
}
fprintf(out,"\n");
}
fclose(out);
exit(0);
}
On 10/8/07, Geoffrey Plitt <[EMAIL PROTECTED]> wrote:
>
> can anyone help?
>
> i'm using the standard example of capture.c; i replaced the process_image
> function, but i can't figure out the format for this buffer. i've gone
> through the docs again
> my code below assumes it's just greyscale values, single-pixel-255. do you
> know what the format is?
>
> On 10/5/07, Geoffrey Plitt <[EMAIL PROTECTED]> wrote:
> >
> > Nate,
> >
> > Thanks again for your help. I've got some progress. I modified the
> > process_image function to write out a PGM file:
> >
> > static void
> > process_image (const void * p)
> > {
> > FILE *out = fopen(" out.pgm ", "w");
> > fprintf(out,"P2\n");
> > fprintf(out,"#CREATOR: ggp\n");
> > fprintf(out,"640 480\n");
> > fprintf(out,"255\n");
> >
> > int x;
> > int y;
> > unsigned char * pixel = p+1;
> > for(x=0; x<WIDTH; x++)
> > {
> > for(y=0; y<HEIGHT; y++)
> > {
> > fprintf(out,"%u ",*pixel);
> > pixel++;
> > }
> > fprintf(out,"\n");
> > }
> > fclose(out);
> > exit(0);
> > }
> >
> > but I don't think I understand the contents of the buf completely.
> > Attached is the resulting image - I can see the flourescent light in there,
> > but there are error patterns all over.
> >
> > Any ideas?
> >
> > -Geoff
> >
> > On 10/5/07, Nathanael Galpin < [EMAIL PROTECTED]> wrote:
> > >
> > > Hey Geoff,
> > >
> > >
> > >
> > > This is a great file to start with. In fact it's what I used first.
> > > Couple things make it a bit tricky. One is that he's using switch
> > > statements
> > > to separate different ways to read from the cameras, so you'll want to
> > > note
> > > which method you're using, (should be MMAP).
> > >
> > >
> > >
> > > The line where he actually captures a frame is in the read_frame
> > > function.
> > >
> > >
> > >
> > > (-1 == xioctl (fd, VIDIOC_DQBUF, &buf))
> > >
> > >
> > >
> > > This blocks until it's able to deque a frame from the camera (unless
> > > you specify non-blocking when you open the cam file, in which case it
> > > returns -1 when it can't immediately deque a frame). You can get at the
> > > raw
> > > frame data through the buf struct.
> > >
> > >
> > >
> > > A little farther down, he re-enques the buffer after he's finished
> > > with with this line:
> > >
> > >
> > >
> > > (-1 == xioctl (fd, VIDIOC_QBUF, &buf))
> > >
> > >
> > >
> > > You can read through the V4L2 spec a bit at bytesex.org to check out
> > > the parameters of the buf struct.
> > >
> > >
> > >
> > > If you want to display this data, a quick way to do it would be to
> > > pull the Y values from the buffer and use these to write a grayscale image
> > > to the screen. I used a Qt picture object when I first started doing this,
> > > and that actually worked quite well.
> > >
> > >
> > >
> > > Hope that helps, and good luck!
> > >
> > >
> > >
> > >
> > >
> > > -- Nathanael
> > >
> > >
> > > ------------------------------
> > >
> > > *From:* [EMAIL PROTECTED] [mailto:
> > > [EMAIL PROTECTED]<[EMAIL PROTECTED]>.berlios.de<[EMAIL PROTECTED]>]
> > > *On Behalf Of *Geoffrey Plitt
> > > *Sent:* Thursday, October 04, 2007 9:18 PM
> > >
> > > hey christopher. this file looks promising, but it doesn't do
> > > anything with the frames. i compiled/ran and it just prints dots, you have
> > > to take as faith that it's capturing - it doesn't output or save the
> > > frames.
> > > in fact, i can't tell exactly where in the code it actually grabs a frame
> > > and has access to the frame's pixel buffer. any clues?
> > > -geoff
> > >
> > > On 10/4/07, *Christopher HORLER* <[EMAIL PROTECTED]> wrote:
> > >
> > > http://v4l2spec.bytesex.org
> > > /v4l2spec/capture.c<http://v4l2spec.bytesex.org/v4l2spec/capture.c>
> > >
> > >
> > >
> > >
> >
> >
>
_______________________________________________
Linux-uvc-devel mailing list
[email protected]
https://lists.berlios.de/mailman/listinfo/linux-uvc-devel
