Board index » delphi » Efficiency of JPEG conversion

2005-06-16 06:48:12 AM
delphi42
Hello, I have written a video capture program for a digital camera. I
have the option to store as bmp or jpg. I am saving the jpeg as shown
below, while the bmp is done similarly but without the conversion.
I've found that the conversion to jpeg is slowing down my app
significantly. The frame rate goes down from 7+ to a little better than 5
frames per second. If I use the routines built into the camera control to
save the images the opposite is true. It is able to save to jpeg much
quicker than to bmp. Internally to the control the image is in YUV
format, but I can not get at it, that may explain the differences.
I'm hoping there is a quicker way of converting from bitmap to jpeg. The
graphics32 library doesn't seem to be the answer. Any other ideas?
cheers
Marc Pelletier
Goldak Airborne Surveys
procedure TCamera.SaveJPeg(fBMP:TBitmap; Filename:string; Comp:integer );
var
MyGraphic : TJPegImage;
S: TFileStream;
begin
MyGraphic := TJpegImage.create;
Try
MyGraphic.CompressionQuality := Comp;
MyGraphic.Assign( fBMP );
if fSaving then
begin
S := TFileStream.Create(Filename, fmCreate or fmShareExclusive);
try
MyGraphic.SaveToStream( S);
finally
S.Free;
end;
end;
finally
MyGraphic.Free;
end;
end;
 

Marc Pelletier writes:
stores the .jpg faster than the .bmp just means that the storage medium
(CF?) is so slow that the saved time on a smaller-jpeg-save more than
compensates for the time it takes to compress the image. (while your PC has
a comparably fast harddisk). Plus the camera may have a hardware jpeg
encoder which works more efficiently than a solution purely based on
software.
Unless this is the final step (ie you don't manipulate the images any
further) I wouldn't save the images in (lossy) jpeg at all...
--
Ben
 

Marc,
The only overhead I see is the Create/Free calls for MyGraphic and S.
Can you move them to the constructor/destructor? You might also want to
change S to a TMemoryStream and the code would be something like this:
if fSaving then
begin
MyGraphic.CompressionQuality := Comp;
MyGraphic.Assign( fBMP );
S.Seek(o,soFromBeginning);
MyGraphic.SaveToStream(S);
S.SaveToFile(FileName);
end;
HTH,
Ronaldo
 

Marc Pelletier <XXXX@XXXXX.COM>wrote in
earlier, the reason your camera can do it faster is it probably has built
in JPEG hardware and it is faster to stores the compressed JPEGs than the
bmps.
What format of JPEG are you using? Sequential or Progressive?
Are you using subsampling?
I have Delphi JPEG source code at www.colosseumbuilders.com. However, I
don't know if it is any faster than that graphics32. On the other hand,
you may be able to optimize it to get it to go faster.
 

You may want to give a try to David Taylor's JpegIO which uses the Intel
Jpeg Library and should compress to Jpeg faster:
www.david-taylor.pwp.blueyonder.co.uk/software/components.html
Eric
 

Jim Slade <XXXX@XXXXX.COM>wrote in news:XXXX@XXXXX.COM:
camera. Its a sony dfw-sx900 digital firewire camera. There's no storage
onboard. I control the camera via an activeX object (ActiveDCam ) which is
based on a freeware camera driver. In both cases storage is to my hard
drive and the differences are purely software.
As to the format of JPG, its Sequential. I turned progressive on in
response to your query, it was REALLY bad.
cheers
Marc
 

Eric Grange <XXXX@XXXXX.COM>wrote in
I'm checking that out now.
Marc
 

Marc Pelletier <XXXX@XXXXX.COM>wrote in
I would have expected progressive encoding to be much slower.
 

Ben Hochstrasser writes:
there are less bytes to store so storage is quick.
makers often over-compress the images. Lost quality cannot be redeemed.
It is always best to buy the largest memory-card you can afford (512
meg or a gig) and compress the BMP later on the PC with software that
has adjustable JPEG quality.
My own exponential compression (wehner.org/compress ) is
lossless, but not yet a standard.
Charles Douglas Wehner
 

There is one option that might solve this more efficiently.
Namely to put the conversion into a thread.
For each frame you capture, spawn a thread and feed the BPL data to it as a
stream, making it comletely isolated. If somthing goes wrong, the exception
will fire in the thread and dont{*word*222}up your main app.
In the OnTerminate event of the thread, store the JPEG stream produced by
the thread (published read only property) to disk and release the thread.
Use a thread list to keep track of threads, and a critical section call to
limit the number of active threads to say, 25 (will limit you to 25 FPS,
albeit not true FPS..).
Hope it helps
Jon Lennart Aasenden
"Marc Pelletier" <XXXX@XXXXX.COM>writes

Jim Slade <XXXX@XXXXX.COM>wrote in news:XXXX@XXXXX.COM:
flow will be simpler if I handle all of them more or less the same.
I will be using the jpeg unit in some other related stuff as well, though,
and want to be sure I am using the best implementation available...
cheers
Marc