> Ack, I wish. This one's a one-way. It pulls the data off the Palm to
> the PC, then converts and dumps JPG to the disk. You never really
> even get a chance to see one of the images in its native format
> outside the pdb - if it has one, that is.
Time is the only limiting factor. You can go both ways. Ther'es a
project on freshmeat which talkes to a digicam. I actually ripped apart
the code for a serial sniffer I was trying to construct.
In any case, a full sync would be a good thing, but I can't really
see the need to put images which are already on the desktop... onto the
camera again, unless you're using the camera as a rudimentary CF reader.
That would be a neat idea for reviving the use of "the second worst
digicam in the world".
> I did this with the easiest one first - all black. Unfortunately, my
> best efforts to get a perfectly black image are falling short - it
> doesn't seem capable of taking one. There are always artifacts,
> amusingly enough the same general patterns no matter how I try to
> enforce darkness (make light a protected inheritance..?) so it seems
> that there may be a tad bit of that Suck factor on this one?
How about keep the lens cap on. ?
> It might be amusing at some point to simply flip a few bits in an
> image, upload the pdb back onto the device, then pull it back through
> the conduit..
What we actually need is an abstraction. Let's remove the image
itself from the format it's presented in. Something like XML does for data
vs. presentation. Just a thought, and I know I'm out of my league here. I
know how to create and manipulate images like an expert, but not how to
deconstruct them into their binary goo.
/d
_______________________________________________
Pilot-unix mailing list
[EMAIL PROTECTED]
http://hcirisc.cs.binghamton.edu/mailman/listinfo/pilot-unix
