repeat post: xcam frontend for SANE

David Mosberger-Tang (davidm@azstarnet.com)
Mon, 27 Jan 1997 10:16:59 -0700

I just noticed that this mail never made it to sane-devel. It's a bit
dated, but may still prove informative. Caveat: 0.42 is just about to
be released (hopefully tomorrow) and there were many xcam
fixes/improvements (especially in the area of TrueColor rendering).

Enjoy,
--david

---
Well, I just couldn't have it that I had to fall back to xqcam to get
some "video" out of my QuickCam.  So I quickly implemented a GTK-based
frontend.  I'm sure it has lots of bugs left, but it seems to work
reasonably well on my Alpha (I shall test it on an x86 sometime soon).
Mind you, it doesn't attempt to save the video stream etc, but it's
quite handy for tuning the camera to the right parameter set.  I have
tested it on 8 bit displays only, though 15, 16, 24, and 32 bit
displays should work too (let me know if you test this).

The neat thing is that you can use xcam even to display images acquired with the PNM backend. So you don't really have to have a video camera to take a peek at xcam.

BIG CAVEAT: I had to get the GTK library that comes with the December 1996 snapshot of GIMP. Earlier versions gave me some bad core dumps in certain situations. With the latest snapshot, I have not had any problems so far.

It's all at:

ftp://ftp.azstarnet.com/pub/linux/axp/sane/sane-0.41.tar.gz

Tristan: you'll find a file called frontend/gtkglue.c that is liberally sprinkled with code that I stole from xscan. The xcam and xscan frontends should be able to share a big amount of code so I started moving everything that ought to be shareable into gtkglue.c. I haven't changed xscan to use gtkglue yet, however (didn't want to mess up your code). Maybe you could take a peek at it and let me know what you think? Another area where code could be shared is for the preview window (image-dithering, scaling, selection, and all).

Finally, I found that the "first_frame" field in the parameter structure to be rather useless. I'd much prefer to have a "last_frame" field that tells you when the last frame in an image arrived. Anybody have any objections to this? I can think of a reason to want "first_frame" (since it will always be true for the first frame after sane_start), but "last_frame" would be extremely handy (e.g., xcam would decode/buffer frames until it hits the last_frame, and then actually render the collected image).

Enjoy, --david

---
Source code, list archive, and docs: http://www.azstarnet.com/~axplinux/sane/
To unsubscribe:    echo unsubscribe sane-devel | mail majordomo@azstarnet.com