Welcome to LEAD Support Forum Login | Register | Faq  

    LEAD Support Forum
  Resource to find answers and post technical questions about LEAD products.
Search    
   

Re: Betreft: Re: Betreft: Re: Betreft: Re: LGRY
Started by Slager at 03-22-2007 2:36. Topic has 11 replies.

Print Search « Previous Thread Next Thread »
  03-22-2007, 2:36
Slager is not online. Last active: 6/18/2008 10:19:29 AM Slager

Top 50 Posts
Joined on 05-02-2006
Posts 35
Optimize ChangeToDIB
Reply Quote
The function LChange::ChangeToDIB first copies the internal bitmap data and then deletes is own memory buffer.
To increase compatibly with for instance GDI+ functions and custom processing functions, it would be nice when this internal buffer would default have a BITMAPINFOHEADER.
In case of a ChangeToDIB function call, Leadtools can determine if it is a gdi compatible format and if so, it directly can pass its internal buffer.

Now using an “external” processing function based on a DIB, using the functions LChange::ChangeToDIB and LChange::ChangeFromDIB needs to take the following steps:
first allocates memory for the DIB then
copies the bmp data and after the “external” processing,
the LeadBitmap has to allocate its internal memory
and copy the data back and
then destroy the DIB data.

   Report 
  03-22-2007, 7:22
Slager is not online. Last active: 6/18/2008 10:19:29 AM Slager

Top 50 Posts
Joined on 05-02-2006
Posts 35
alternative
Reply Quote
As an alternative; maybe less action a static HGLOBAL loadToDIB(L_UINT uType) function can be added { where uType: DIB_BITMAPINFOHEADER, DIB_BITMAPV4HEADER, DIB_BITMAPV5HEADER }
Based on this dib the user can keep the responsibility for the memory management by using the LBitmapBase functions:
LBitmapBase::Initialize( … );
LBitmapBase::Allocate( TYPE_USER );
BITMAPHANDLE* pHandle = LBitmapBase::GetHandle( );
pHandle->Addr.Compressed.pData = calcpixelpntr( )
pHandle->Addr.Windows.pData = calcpixelpntr( )
pHandle->Addr.Tiled.pData = calcpixelpntr( )
pHandle->Addr.SuperCompressed.pData = calcpixelpntr( )
   Report 
  03-23-2007, 4:04
Slager is not online. Last active: 6/18/2008 10:19:29 AM Slager

Top 50 Posts
Joined on 05-02-2006
Posts 35
LGRY
Reply Quote
Besides it would also be nice when lead support its own FOURCC Codec: LGRY (LGRYINFOHEADER) format for the dib functions, for 12&16 bits grayscale images.
   Report 
  03-26-2007, 10:31
Adnan Ismail is not online. Last active: 8/14/2008 1:40:07 PM Adnan Ismail



Top 10 Posts
Joined on 07-31-2006
Posts 1,124
Re: LGRY
Reply Quote

Some of this functionality is already implemented in LEADTOOLS. If you call LChange::ChangeFromDIB it will try to use the DIB data itself without making a copy, if that is possible.

However, implementing some of the other features, such as allowing the programmer to access the internal bitmap pointer directly, will require major design changes in LEADTOOLS.


Adnan Ismail
LEADTOOLS Technical Support

   Report 
  03-27-2007, 2:33
Slager is not online. Last active: 6/18/2008 10:19:29 AM Slager

Top 50 Posts
Joined on 05-02-2006
Posts 35
Betreft: Re: LGRY
Reply Quote
That is what i expected, from the LChange::ChangeFromDIB function.
But when I create a Leadtools bitmap in a dib compatible format, it doesn’t internally use a dib.

LBitmap bmpTst( 640, 480 );
BITMAPHANDLE* pHandle = bmpTst.GetHandle( );

Now add the address of pHandle->Addr.Windows.pData; to a memory window, in your debug environment.

HGLOBAL handleDib = LChange::ChangeToDIB( &bmpTst );

When you step over the LChange::ChangeToDIB, you can see the memory, is invalidated.

The LChange::ChangeToDIB function returns a pointer to one memory block; this means that if LChange::ChangeToDIB will be able to “give through” a dib, Leadtools internally must have added an InfoHeader before its pixel data buffer.

   Report 
  03-27-2007, 2:47
Slager is not online. Last active: 6/18/2008 10:19:29 AM Slager

Top 50 Posts
Joined on 05-02-2006
Posts 35
Betreft: Re: LGRY
Reply Quote
About “access the internal bitmap pointer”, I was maybe a bit unclear.

When I create a bitmap with LBitmapBase::Allocate( TYPE_USER ), like I mentioned under “alternative”, I first create a dib by myself.

When I calculate where the pixel data starts within this dib, I can set the pHandle->Addr pixelpointers, from the Leadtools bitmap.
Under this circumstance I am able to share the dib pixeldata with leadtools. (Both have direct access to the same memory block)

In case of creating a bitmap this works, but in case of loading a bitmap, the load function allocates its own memory.
When Leadtools would provide a static load function (like change to dib) which returns a dib, I will be able to create from this dib a leadtools bitmap as I mentioned above.

   Report 
  03-29-2007, 12:48
Adnan Ismail is not online. Last active: 8/14/2008 1:40:07 PM Adnan Ismail



Top 10 Posts
Joined on 07-31-2006
Posts 1,124
Re: Betreft: Re: LGRY
Reply Quote

You can load any type of image into your own buffer without having to load first into conventional memory then copying to user memory.
I haven't tried this, so I will give you a couple of ideas.

First approach:
Allocate a TYPE_USER bitmap and use the LFile::LoadFile() function without the LOADFILE_ALLOCATE flag.
You might have to implement the LFile::LoadFileCallBack function and fill the data yourself instead of using the LOADFILE_STORE.

Second approach:
Don't use LOADFILE_ALLOCATE or LOADFILE_STORE but implement the LFile::LoadFileCallBack function and use LFile::LoadFile().
In the callback function, store the data into your own buffer and when it's full, create a new bitmap with of TYPE_USER.

The 2 approaches are similar, but one of them creates the bitmap first then loads, while the other loads first then creates the bitmap.
Adnan Ismail
LEADTOOLS Technical Support

   Report 
  04-05-2007, 3:44
Slager is not online. Last active: 6/18/2008 10:19:29 AM Slager

Top 50 Posts
Joined on 05-02-2006
Posts 35
Betreft: Re: Betreft: Re: LGRY
Reply Quote
Adnan, thanks for pointing me in the right direction.

I tried creating the LeadTools Bitmap first Based on a dib (based on CTCLFile::GetInfo() ) and then using the LFile::LoadFile without the LOADFILE_ALLOCATE flag and with LOADFILE_NOINITBITMAP flags. I tried several things based on this approach but or the pixel pointers where set to zero or the function failed on invalid parameter, despite the bitmap handle was filled in correctly.

The second approach using the LoadFileCallBack( ), within a LFile derived class worked.
The first time when the CallBack function is called, I create my dib, based on the LeadTools m_bmp parameters. The LeadTools bmp will not be created, but the parameters (bitspp/width/...) will be filled in by Lead, before the first callback.

There is one small thing; the pixeldata is given trough by LeadTools LBuffer object (per nLines).
I wanted to directly let Lead write into my dib pixel data buffer, now there is one copy action from LBuffer to my dib pixel data buffer, but this is acceptable.


bool CTCLFile::LoadFile( CString cFile )
{
LFile::SetBitmap( &m_bmp ); //empty bmp
LFile::SetFileName( ( L_TCHAR L_FAR * ) ( LPCTSTR ) cFile );
LFile::EnableCallBack( TRUE );

LFile::LoadFile( 0,
ORDER_BGRORGRAY,
0,
NULL,
NULL );

return m_Dib.IsValid( ); //m_Dib = dib wrappr
}

L_INT CTCLFile::LoadFileCallBack(
pFILEINFO pFileInfo,
LBitmapBase L_FAR* pLBitmap,
LBuffer L_FAR* pLBuffer,
L_UINT uFlags,
L_INT nRow,
L_INT nLines )
{

}

Regards,

Slager

   Report 
  04-08-2007, 12:49
Adnan Ismail is not online. Last active: 8/14/2008 1:40:07 PM Adnan Ismail



Top 10 Posts
Joined on 07-31-2006
Posts 1,124
Re: Betreft: Re: Betreft: Re: LGRY
Reply Quote
Slager,

I managed to load the bitmap directly into my own buffer without using the callback or making a copy operation using the following code:

static unsigned char myBuffer[20*1024];
memset(myBuffer, 200, sizeof(myBuffer));
L_INT nRet = L_CreateBitmap(&Bitmap, sizeof(Bitmap), TYPE_USER, 90, 72, 24, ORDER_BGR, NULL,
   TOP_LEFT, myBuffer, sizeof(myBuffer));
InvalidateRect(hWnd, 0, TRUE);
MessageBox(hWnd, "Before Loading. Should be light gray", "Test User Buffer", MB_OK);
nRet = L_LoadFile("I:\\TestFolder\\small2.bmp", &Bitmap, sizeof(Bitmap), 0, ORDER_BGR,
   LOADFILE_NOINITBITMAP | LOADFILE_STORE, 0, 0, 0, 0);
InvalidateRect(hWnd, 0, TRUE);
MessageBox(hWnd, "After Loading", "Test User Buffer", MB_OK);

L_AccessBitmap(&Bitmap);
memset(myBuffer, 70, sizeof(myBuffer));
L_ReleaseBitmap(&Bitmap);

InvalidateRect(hWnd, 0, TRUE);
MessageBox(hWnd, "After filling with dark gray", "Test User Buffer", MB_OK);


Adnan Ismail
LEADTOOLS Technical Support

   Report 
  04-10-2007, 5:11
Slager is not online. Last active: 6/18/2008 10:19:29 AM Slager

Top 50 Posts
Joined on 05-02-2006
Posts 35
Betreft: Re: Betreft: Re: Betreft: Re: LGRY
Reply Quote
Adnan,

Perfect!!

Normally I am using the wrapper classes so my code will look something like this:


void LoadBitmap( const CString& cFile, LBitmap* pBmp )
{
LFile lfile;
BYTE* pBuff = NULL;
L_INT nRet;
BITMAPHANDLE bitmap;
FILEINFO FileInfo;
LOADFILEOPTION LoadfileOption;

ZeroMemory( &LoadfileOption, sizeof( LOADFILEOPTION ) );
ZeroMemory( &FileInfo, sizeof( FILEINFO ) );

LoadfileOption.uStructSize = sizeof( LOADFILEOPTION );
FileInfo.uStructSize = sizeof( FILEINFO );


lfile.SetFileName( ( L_TCHAR L_FAR * ) ( LPCTSTR ) cFile );
nRet = lfile.GetInfo( &FileInfo, sizeof( FileInfo ), FILEINFO_TOTALPAGES, &LoadfileOption );

if ( SUCCESS == nRet && FileInfo.SizeMem > 0 )
{
pBuff = new BYTE[ FileInfo.SizeMem ];
}

if ( pBuff )
{
L_CreateBitmap( &bitmap, sizeof( bitmap ),
TYPE_USER,
FileInfo.Width,
FileInfo.Height,
FileInfo.BitsPerPixel,
ORDER_BGR,
NULL,
BOTTOM_LEFT,
pBuff,
FileInfo.SizeMem );

L_LoadFile( ( L_TCHAR L_FAR * ) ( LPCTSTR ) cFile, &bitmap, sizeof( bitmap ), 0, ORDER_BGR,
LOADFILE_NOINITBITMAP | LOADFILE_STORE, 0, 0, 0, 0 );
}

if( pBmp )
{
pBmp->SetHandle( &bitmap );
}

}

Thanks for your support!

   Report 
  05-21-2008, 18:44
DCurtis is not online. Last active: 6/11/2008 2:40:59 PM DCurtis

Top 150 Posts
Joined on 02-09-2007
Posts 18
Re: Betreft: Re: Betreft: Re: Betreft: Re: LGRY

Attachment: ViewPerspectiveProblem.zip
Reply Quote
That works fine unless you try to open a file that has a rotated view perspective (like TOP_LEFT90). Any ideas how to make it work for that case?

A sample jpeg file is attached that shows the problem.

   Report 
  05-22-2008, 2:54
Amin is not online. Last active: 8/7/2008 10:50:51 AM Amin



Top 10 Posts
Joined on 06-27-2005
Posts 748
Re: Betreft: Re: Betreft: Re: Betreft: Re: LGRY
Reply Quote
This issue will be addressed in this forum post:
http://support.leadtools.com/SupportPortal/cs/forums/21213/ShowPost.aspx


Amin Dodin
LEADTOOLS Technical Support

   Report 
Post
LEAD Support Fo... » General » Feature Request... » Re: Betreft: Re: Betreft: Re: Betreft: Re: LGRY

Powered by Community Server, by Telligent Systems