Tek-Tips is the largest IT community on the Internet today!

Members share and learn making Tek-Tips Forums the best source of peer-reviewed technical information on the Internet!

  • Congratulations SkipVought on being selected by the Tek-Tips community for having the most helpful posts in the forums last week. Way to Go!

Converting a bitmap generated by a webcam to a jpg 1

Status
Not open for further replies.

tedsmith

Programmer
Nov 23, 2000
1,762
0
0
AU
I am trying to find ways to improve converting a bitmap generated by a webcam to a jpg so it can be sent faster via a network to another computer.

My problem is -

I tried GDIplus as per an old strongm examples with, instead of saving the jpg to file, I used:-
GdipCreateFromHDC Picture2.hDC, myGraphics
GdipDrawImage myGraphics, gdiImageTarget, 0, 0

This does quickly paint a jpg picture over a picturebox but this is wiped out by any object moving over it and it's .picture = 0 so there is nothing to send! It seems to be drawing only to the screen, not the picturebox.

Is there a way of using GDIplus to produce a data stream or fill a picturebox.picture like a loadpicture statement does so it can be sent over a network?

Currently I use AviCap32 feeding the webcam to the clipboard.
I then send the BMP in the clipboard over the network in a propertybag without any problem.

Using GDIplus I am able to capture the picture and convert it to the jpg picture'painted'box but I cant send this picture to the network.

GDIplus often freezes the app when you close it needing removal by task manager processes.

I haven't been able to get WIA to work on Win7 so I cant use this either unless someone has an answer to this separate problem!
 
Thanks dilettante.
I am not trying to say you are wrong, it's just that I was getting what appeared to me to be conflicting advice or opinions from two well respected and obviously very experienced contributors.

I did not realise this could happen here because, in my limited experience, although I have done a lot of practical testing in an attempt to get 100% reliability, I have never seen a dataarrival accidentally receive less than 4 bytes of a larger message except at the very end of a transmission that is a few bytes bigger than a multiple of 8k in which case it would be part of the picture and wasn't looking for a long anyway. (I know it it often happens with RS232 serial with a fast computer)

Do you think it would be better then if I received the whole of a transmission in to a large array or string and separated any text after the last was received? (in other words a sort of propertybag like I originally had?)

I not asking how to code it, just the method.

Thanks Strongm do you mean No it would have a bearing or No it wouldn't have a bearing?
 
>Thanks Strongm do you mean No it would have a bearing or No it wouldn't have a bearing?

The latter. My example (and modifications) were not related to your later requirements.
 
Happy to tell you that I have worked out a simple and quick way to reliably send mixed pic streams and text.
I use strongm's methods of first sending the size of the data then using this size value to collect all the data.
No propertybags needed.
To differentiate between pis and other, because a pic is far larger, when I initially measure the received size, if it is under 255 bytes I treat it completely separately as text. I use the next byte after the size as a code for what sort of other data follows (OK's, text or numbers.)
When sending text, I use bytes equal to the ascii value of the text rather than strings to keep the same type of data transmission for both.
Works flawlessly so far with nothing getting mixed up.

If by chance less than 255 bytes of picture is first received, it is still treated as picture because I am using the sent size in the first 4 bytes and not ubound(buffer).

The problem of using getdata format clng is fixed by only getting data when bytestotal > 3 and as far as I can measure it never lies. If <4, Dataarrival fires again and gets it on the next round.

The end result is 20 times faster than my original.

If anyone wants to be bored with the code I can post it.

Thanks everyone.
 
I'm not sure if you have a need for it, but playing around with this stuff a little more I ran into the need for YUV-decoding with newer webcams. I've also added image timestamping you may or may not need.

AVICap32 Cam Streaming w/o Clipboard

Seems to even work on Win95 OSR2, works with Vista 32- and 64-bit. I don't have a Win7 machine without multiple webcams though, which seems to be a problem. I'll probably try another Win7 machine soon.
 
thanks
You certainly have put a lot of work into it!

I am trying to get two types of "modern" webcam to work with Windows 98 (but not at the same time).
Please don't ask why I am trying to do such a stupid thing!

They are a 3 yr old Logitec Quickcam Communicate and a new Windows Lifecam

They both work well using their own drivers in Win 7 64b but I can't locate any drivers that work in Windows 98.

Win7 64 automatically installs their different drivers on the run when you pull one camera out and substitute the other without having to even restart my VB6 app (using AVIcap).

I there perhaps something like an API or driver for any OS that can be used with vb6 instead of OS specific drivers? (in Win98?)
 
I was getting a lot of "help" here ("What about...?" "It is leaking memory." sorts of things). Hot weather here of late so plinking around with AviCap, GDI and GDI+ was an indoor diversion - I'm not a graphics guy.

The only cameras I have gotten to work on Win9x are two old Logitech cams (old black "ball" VC, newer grey "ball" QC Express, micro-camera Blink StyleCam which has a webcam mode). A few more work on Win2K and XP but no later (no Vista or Win7 drivers). Newer cameras like Kinobo Origami work on Vista and Win7, probably on XP too, but don't even come with a driver disk. I haven't tried one of these on Win9x yet.
 
One nagging thing though...

Since you can buy an IP webcam now for well under $100 isn't this sort of thing a little obsolete? The ones I looked at can be operated wired or wireless, support remote pan and tilt, "night vision" mode, etc. No need for the cost and support of a PC at each camera location.
 
Status
Not open for further replies.

Part and Inventory Search

Sponsor

Back
Top