🚀 go-pugleaf

Peter Fagerbrant wrote:

> LRESULT PASCAL FrameCallbackProc(HWND hWnd, LPVIDEOHDR lpVHdr)
> { <snip>
> 
> I do some imgageprocessing directly on the bitmap arays.
> 
> My problem.
> Now I have a new USB camera where I only can set the driver to jpeg.

> Any sugestions?

Can you assign the data to a stream and then to a TJPEGImage ?

#include <jpeg.hpp>

   TJPEGImage *JPEGImage = new TJPEGImage;

   JPEGImage->LoadFromStream ( .... )

   Graphics::TBitmap *Bitmap = new Graphics::TBitmap;

   Bitmap->Assign ( JPEGImage);

   // use bitmap        \

   delete Bitmap;

   delete JPEGImage;

Hans.

>> Any sugestions?
>
> Can you assign the data to a stream and then to a TJPEGImage ?
I have not been so successful in this yet. I am working on it right now.


>   TJPEGImage *JPEGImage = new TJPEGImage;
>
>   JPEGImage->LoadFromStream ( .... )
>
>   Graphics::TBitmap *Bitmap = new Graphics::TBitmap;
>
>   Bitmap->Assign ( JPEGImage);
>
>   // use bitmap        \
>
I would prefer to manage without the TBitmap. As of my understanding the 
TJPEGImage does contains the bitmap if I call the DIBNeded, but its read 
only. Or is it unacessible completly?
My tought was to read the bitmap and copy it to the bitmaparray becuse my 
application depends on the bitmaparray in more the a couple of places.

reg
/PFa 

Peter Fagerbrant wrote:

> I would prefer to manage without the TBitmap. As of my understanding the 
> TJPEGImage does contains the bitmap if I call the DIBNeded, but its read 
> only. Or is it unacessible completly?

<from help>
TJPEGImage has an internal bitmap that represents the jpeg image.
This internal image and the original source of the jpeg image are read only.

The following are characteristics of this object. A TJPEGImage object:

         Provides no access to the internal bitmap image
         that it creates for the JPEG image.
</fom help>
	
Read only and not accessible is a contradiction.

> My tought was to read the bitmap and copy it to the bitmaparray becuse my 
> application depends on the bitmaparray in more the a couple of places.

You could transfer the data yourself from the extra TBitmap to your
bitmap array.

Hans.

Hans Galema wrote:

>         Provides no access to the internal bitmap image
>         that it creates for the JPEG image.

   Graphics::TBitmap *Bitmap = new Graphics::TBitmap;

   Bitmap->Assign ( JPEGImage->Bitmap);

Will not compile because Bitmap is inaccessible. But ..

#include <jpeg.hpp>

class THackJPEGImage : TJPEGImage
   {
    public:
     __property Bitmap;
   } ;

   Graphics::TBitmap *Bitmap = new Graphics::TBitmap;

   Bitmap->Assign ( ((THackJPEGImage*)JPEGImage)->Bitmap);

does compile. And it assigns. So you could use the intern
Bitmap in this way directly.

Hans.

Hans Galema wrote:

> does compile. And it assigns. So you could use the intern
> Bitmap in this way directly.

But you can even modify it. Here is my complete test:

void __fastcall TForm1::BitBtn1Click(TObject *Sender)
{
   TJPEGImage *JPEGImage = new TJPEGImage;

   JPEGImage->LoadFromFile ( ExtractFilePath ( ParamStr(0) ) + "PICT0003.jpg" );

   Graphics::TBitmap *Bitmap = new Graphics::TBitmap;

   //Bitmap->Assign ( JPEGImage); // works ok
   //Bitmap->Assign ( JPEGImage->Bitmap); // does not compile

   ((THackJPEGImage*)JPEGImage)->Bitmap->Canvas->TextOut ( 0, 0, "AAAA" );

   Bitmap->Assign ( ((THackJPEGImage*)JPEGImage)->Bitmap);

   Image1->Picture->Bitmap->Assign ( Bitmap );              \

   delete Bitmap;

   delete JPEGImage;
}

Hans.

>   ((THackJPEGImage*)JPEGImage)->Bitmap->Canvas->TextOut ( 0, 0, "AAAA" );
>
>   Bitmap->Assign ( ((THackJPEGImage*)JPEGImage)->Bitmap);
>
>   Image1->Picture->Bitmap->Assign ( Bitmap );              \
>
>   delete Bitmap;
>
>   delete JPEGImage;

Thanks Hans.

I got it working now.
I using:
BYTE *MemPtr = lpVHdr->lpData;
stream->Write(MemPtr, lpVHdr->dwBytesUsed);
stream->Position = 0;
JPEGImage->LoadFromStream ( stream );
Bitmap->Assign ( JPEGImage);

But I am going to try your "hack" and se if it's faster.
I making a aplikation that measures a drop of water. Angle, Height, Volume 
etc.
I  need the speed becuse I measure while the waterdrop absorbs or dunsting.

Many thanks

best reg
Peter Fagerbrant 

Peter Fagerbrant wrote:

> I making a aplikation that measures a drop of water. Angle, Height, Volume 
> etc.

Nice challenge.

You process the bitmap data to extract info ? Great challenge.

The drop does not fall ?

Hans.

>
> You process the bitmap data to extract info ? Great challenge.
Yes I process the bitmap dat, thats why I need the speed.

> The drop does not fall ?
It does ;)

I make the software for the instruments found here 
http://www.pocketgoniometer.com/

Sometimes the drop falls very fast. For this application I only need the USB 
webcamera with 25-30 frames/sek, in faster systems I use a framegrabber card 
and its SDK to take more than 1000 frames per sek to process.

This was the first time I needed to process jpeg. Before I could select 
RGB24, but not in the new camera I evaluate. I am a bit worried about the 
qualityloss in the jpeg format. Its critical for me to have clear and 
correct edges in the image.
As of my understanding, this is where jpeg does not suit.
Problem is, most cameramanufacturer uses jpeg to speed up the transmisson. 
RGB is to large.

best reg
/Peter Fagerbrant 

Peter Fagerbrant wrote:

>>The drop does not fall ?
> 
> It does ;)

> I make the software for the instruments found here 
> http://www.pocketgoniometer.com/

Nice that 'contact angle' is explained.

Do you mean the fall during
<quote>
Empirically we have found that a water droplet of 2-4 microlitre can
be applied from a distance of two millimetres without any negative impact.
</quote>

Or just for any drop ? During a fall there would be no contact
angle. Or do you mean a fall along a surface ?

Hans.

Hans Galema wrote:
> Peter Fagerbrant wrote:
> 
>>> The drop does not fall ?
>>
>>
>> It does ;)
> 
> 
>> I make the software for the instruments found here 
>> http://www.pocketgoniometer.com/
> 
> 
> Nice that 'contact angle' is explained.
> 
> Do you mean the fall during
> <quote>
> Empirically we have found that a water droplet of 2-4 microlitre can
> be applied from a distance of two millimetres without any negative impact.
> </quote>
> 
> Or just for any drop ? During a fall there would be no contact
> angle. Or do you mean a fall along a surface ?
> 
> Hans.
> 

In theory you can have a contactangle against the athmosphere under the 
fall. But that would be difficult to measure and is not the case :)
Its the contact angle against the surface of some kind. Paper, plastic, 
metal, oil etc.

The fall I refered to is in the highspeed system. When the droplet 
releases from the pipet it falls down to the surface. There are a wish 
from my employer to measure the drop under the fall to make a more exact 
  measure of the volume on the aplied drop before impact at the surface. 
The surface can be high absorbing papers.

/Peter

Hans Galema wrote:

> Do you mean the fall during
> Hans.
> 
Hans, you can look at our main home site at this page 
http://www.fibro.se/html/dynamic_contact_angle.html there you will see a 
falling drop.

/PFa

Peter Fagerbrant wrote:

> ... There are a wish 
> from my employer to measure the drop under the fall to make a more exact 
>  measure of the volume on the aplied drop before impact at the surface. 

Then there is enough work for you.

Thanks for the info.

Hans.

I Use this for storing the bitmapinfo in a array:

for( int y=0;y<CAMRESY;y++){
 xoffsIn = 0;
 BYTE* pLine = (BYTE*) ((THackJPEGImage*)JPEGImage)->Bitmap->ScanLine[y];

 for(  int x=0;x<CAMRESX;x++){
  int r = pLine[ xoffsIn  + 0];
  int g = pLine[ xoffsIn  + 1];
  int b = pLine[ xoffsIn  + 2];

  int iGrey = b*0.11 + g*0.59 + r*0.30;
  pData8Out[ x + yoffsOut ] = iGrey;
  xoffsIn += 3;
  }

 yoffsIn  += CAMRESX+CAMRESX+CAMRESX;
 yoffsOut += CAMRESX;
 }

I do it in realtime. Unfortenly its impacts performens more then I want. The 
camera delivers 30 fps and with this aproach I can only process 12-15 fps.
Is there a faster way to do this?
Is it for example possible to set the bit depht and greyscale directly in 
the JPEGImage component and would it be faster?

Any id�es?

reg
/PFa 

Peter Fagerbrant wrote:

>   int r = pLine[ xoffsIn  + 0];
>   int g = pLine[ xoffsIn  + 1];
>   int b = pLine[ xoffsIn  + 2];
> 
>   int iGrey = b*0.11 + g*0.59 + r*0.30;

> I do it in realtime. Unfortenly its impacts performens more then I want. The 
> camera delivers 30 fps and with this aproach I can only process 12-15 fps.
> Is there a faster way to do this?

Could you do a test to see what the impact on performance is by statement

   int iGrey = b*0.11 + g*0.59 + r*0.30;

Just make it int iGrey = 111; // value does not matter.

Think that those three multiplications are a performance break.

If so than there are possibilities.

> Is it for example possible to set the bit depht and greyscale directly in 
> the JPEGImage component and would it be faster?

Don't know that much about that. You better start a new thread in
borland.public.cppbuilder.graphics where you post your problem.

Please do the test. Could you spend an extra 16MB for a table ?

Hans.

> Could you do a test to see what the impact on performance is by statement
>
>   int iGrey = b*0.11 + g*0.59 + r*0.30;
>
> Just make it int iGrey = 111; // value does not matter.
>
It maked maybe a single frame extra (faster) per second.


> Think that those three multiplications are a performance break.
>
> If so than there are possibilities.
>
Maybe its folish of me to first convert the JPEG stream to RGB24 with the 
TJPEGImage component and then greyscale convert it to 8 bit. Two complex 
algoritms that should be taken care of after the capture and not in the 
callback routine.
Unfortenly my boss incists in the realtime conversion.

>> Is it for example possible to set the bit depht and greyscale directly in 
>> the JPEGImage component and would it be faster?
>
> Don't know that much about that. You better start a new thread in
> borland.public.cppbuilder.graphics where you post your problem.
I'l try to post a question there, thanks Hans.

>
> Please do the test. Could you spend an extra 16MB for a table ?
>
Memory is not an issue here
I already using:
struct CAPIMAGE
{
  DWORD dwTime;
  BYTE Data[CAMRESX*CAMRESY];     //640x480
};

pImages  = new CAPIMAGE[MAXIMAGES];    //MAXIMAGES=50

BYTE* pData8Out = pImages[iIndex].Data;

This is my capturebuffer where I store the captured bitmaps. After the 
capure I do my imageprocessingstuff where i measure and so on.

The only things that do matter is speed. Most of the customer want to see 
what happens under the first second from the impact.

Ok, the speed is not so bad. The old system with the bitmapcamera could 
process 15-16 fps. Now with the decoding of jpeg it processes 13-15 fps. The 
problem is that, my boss do not accept to go under 15fps processing and the 
old bitmapcamera is discontinued by the manufacturer.

Hard life for a simple programmer.

reg/
PFa 

Peter Fagerbrant wrote:

> It maked maybe a single frame extra (faster) per second.

> Memory is not an issue here

But then a table is of no use. How many frmes can you handle
in a second if you omit the 'I Use this for storing the bitmapinfo in a array:'
completely. So just offer an empty array to the next routine.
Keep the rest the same.

I like to know the percentage of time that conversion takes.

Hans.

"Hans Galema" <notused@notused.nl> skrev i meddelandet 
news:41ee43e8$1@newsgroups.borland.com...
>How many frmes can you handle
> in a second if you omit the 'I Use this for storing the bitmapinfo in a 
> array:'
> completely. So just offer an empty array to the next routine.
> Keep the rest the same.
>
> I like to know the percentage of time that conversion takes.
>
> Hans.

Without the for( int y=0;y<CAMRESY;y++) {...}
It runs with 26-30 fps.

When I comment out the for(  int x=0;x<CAMRESX;x++)
but keeps y loop including BYTE* pLine = (BYTE*) 
((THackJPEGImage*)JPEGImage)->Bitmap->ScanLine[y];
It drops to 15fps.

When I commenting out the "JPEGImage)->Bitmap->ScanLine[y];"
Enabling the x loop but only do:
for(  int x=0;x<CAMRESX;x++)
   {
   int r = 11; //pLine[ xoffsIn  + 0];
   int g = 11; //pLine[ xoffsIn  + 1];
   int b = 11; //pLine[ xoffsIn  + 2];

   int iGrey = b*0.11 + g*0.59 + r*0.30;
   pData8Out[ x + yoffsOut ] = iGrey;
   xoffsIn += 3;
   }
It runs on 22-26 fps

It looks like the ScanLine[y]; is the big thief here.

reg/
PFa 

Peter Fagerbrant wrote:

 > BYTE* pLine = (BYTE*)
> ((THackJPEGImage*)JPEGImage)->Bitmap->ScanLine[y];
> It drops to 15fps.

> It looks like the ScanLine[y]; is the big thief here.

Try to call it only twice. Determine the difference of the
two values for pLine. Then further use that difference
to add to the previous start value of pLine to get the
value for the next line.

Well if Scanline[] was an array that would work. But if []
is an operator it would fail. You could just give it a try.

Hans.

> Well if Scanline[] was an array that would work. But if []
> is an operator it would fail. You could just give it a try.
>
> Hans.

I have tried to use scanline[0] to position the pointer at start of the 
bitmap array and then handle it as if it where a array, but receives an AV.
The help states that scanline is:
property void * ScanLine[int Row] = {read=GetScanline};

I run into this at a search on the newsgroup:
"When Scanline property is read(GetScanline is Called) and
TBitmap has DDB and DIB Section or TBitmap has only DDB,
TBitmap discards DIB Section if necessary and
and create DIB Section from DDB without Freeing DDB.

Subsequent References of Scanline proeprty cause same thing.
This behaviour make scanline property extremely slow!!
"
It suggested that I shuld do a 
((THackJPEGImage*)JPEGImage)->Bitmap->HandleType = bmDIB; or a dormant().

This does not help the performance in my case.
I will seek more and see what I can find.

reg/
PFa 

> Well if Scanline[] was an array that would work. But if []
> is an operator it would fail. You could just give it a try.
>
> Hans.

The function look like this:
function TBitmap.GetScanLine(Row: Integer): Pointer;
begin
  Changing(Self);
  with FImage.FDIB, dsbm, dsbmih do
  begin
    if (Row < 0) or (Row >= bmHeight) then
      InvalidOperation(@SScanLine);
    DIBNeeded;
    GDIFlush;
    if biHeight > 0 then  // bottom-up DIB
      Row := biHeight - Row - 1;
    Integer(Result) := Integer(bmBits) +
      Row * BytesPerScanline(biWidth, biBitCount, 32);
  end;
end;

As it says, it do returns a pointer, but limmited to the width of the 
pixelmap.
And it recreates the DIB for every access.

I have no clues to how make it faster. 

Peter Fagerbrant wrote:

> I will seek more and see what I can find.

http://www.google.de/advanced_group_search?hl=de
Just do an extended google newsgroup search for Scanline and
slow in 'Nur Ergebnisse aus der Newsgroup ausgeben' *cppbuilder*.

And put your problem in the ..graphics newsgroup.

Hans.

> And put your problem in the ..graphics newsgroup.
>
> Hans.

Ok , thanks Hans.  I have done that.

Beste Gruesse/
PFa