Some things strange with bcc 5.0

Discussions on GFL SDK, the graphic library for reading and writing graphic files

Moderators: XnTriq, helmut, xnview

josei

Some things strange with bcc 5.0

Post by josei »

Hello

I am using libgfl version 2.11 and when I change to 2.20 or 2.40 there are some strange things like:

1.- Bitmap->BytesPerLine on 2.11 has a value of 1350 (that is ok ) and on 2.20/2.40 it has a value of 1352 (that is not ok)

2.- If i try to load a picture of n bytes on 2.11 I got on

GFL_FILE_INFORMATION info;
....
gflGetFileInformation(_parc(1),_parnl(2),&info);

...

info.FileSize---> has the right value

but with 2.20 or 2.40 it has a really strange value but not the filesize


I use Bcc 5.0.

Thanks in advance
Jose Ignacio Jimenez Alarcon
User avatar
xnview
Author of XnView
Posts: 43163
Joined: Mon Oct 13, 2003 7:31 am
Location: France

Re: Some things strange with bcc 5.0

Post by xnview »

josei wrote:Hello

I am using libgfl version 2.11 and when I change to 2.20 or 2.40 there are some strange things like:

1.- Bitmap->BytesPerLine on 2.11 has a value of 1350 (that is ok ) and on 2.20/2.40 it has a value of 1352 (that is not ok)

2.- If i try to load a picture of n bytes on 2.11 I got on

GFL_FILE_INFORMATION info;
....
gflGetFileInformation(_parc(1),_parnl(2),&info);

...

info.FileSize---> has the right value

but with 2.20 or 2.40 it has a really strange value but not the filesize
Strange a difference of 2 bytes?? Could you send me original file?
Pierre.
User avatar
Ithier
Posts: 47
Joined: Fri Nov 19, 2004 10:50 am
Location: Paris, France

Post by Ithier »

Can the problem be a difference in the packaging of the structures with a 4 byte alignement ?
1350/4 = 337.5
1352 = 338

I had a similar problem when I switched to version 2.20.

Ithier
MaierMan
Posts: 78
Joined: Wed Aug 04, 2004 8:32 pm

Post by MaierMan »

Solution is simple. (As long as this is indeed the reason).
LinePadding member of is initilized to 4 (2.20+) while it was prior 1 (2.11)
Change it back to 1 manually after call to gflGetDefaultLoadParams. ;)

test it yourself:

Code: Select all

#include <windows.h>
#include <stdio.h>
#include <iostream>
#include <libgfl.h>

#pragma link "b_libgfl.lib"

using namespace std;

int main(int argc, char* argv[])
{
    gflLibraryInit();
    GFL_LOAD_PARAMS x;
    gflGetDefaultLoadParams(&x);
    cout << x.LinePadding << endl;
    Sleep(2000);
    return 0;
}
User avatar
xnview
Author of XnView
Posts: 43163
Joined: Mon Oct 13, 2003 7:31 am
Location: France

Post by xnview »

MaierMan wrote:Solution is simple. (As long as this is indeed the reason).
LinePadding member of is initilized to 4 (2.20+) while it was prior 1 (2.11)
Change it back to 1 manually after call to gflGetDefaultLoadParams. ;)
Right, now the padding is 4, better for windows compatibility...
Pierre.
MaierMan
Posts: 78
Joined: Wed Aug 04, 2004 8:32 pm

Post by MaierMan »

xnview wrote:
MaierMan wrote:Solution is simple. (As long as this is indeed the reason).
LinePadding member of is initilized to 4 (2.20+) while it was prior 1 (2.11)
Change it back to 1 manually after call to gflGetDefaultLoadParams. ;)
Right, now the padding is 4, better for windows compatibility...
I know.
But I think this change (between 2.11 and 2.20) is what causes the "issues" experienced here.
Had the problem myself with a routine that accessed the GFL_BITMAP.Data member directly.
Things broke (because the padded bytes were read as well) and I had a hard time figuring out what happend. ;)

That reminds me:
References/Structures/GFL_LOAD_PARAMS wrote:LinePadding
Pad for a pixels line (For example, a value of 4 allow a line padding on 32bits).
Default value : 1
josei

Post by josei »

Hello

First of all, many thanks to all who answered my question.

Well with linepadding=1 the problem with the two extra bytes is now resolved.

But I have the second problem

The size on windows of a image (dicom) is 524288 bytes with 2.11 I got on Filesize this value but with 2.40 I get the following value 13293124

With a jpg file of 69635 bytes with 2.11 I got this value but now I get 13296832

I use the followings settings


load_option.Flags |= GFL_LOAD_SKIP_ALPHA;
load_option.Origin = GFL_BOTTOM_LEFT;
load_option.ColorModel = GFL_BGR;

I don´t know if there is any diference but I have a c function that modify the defaulf file selection dialog of windows to show a thumbnail, like xnview, and one of the fields is filesize...it shows the right file size.

Yours

Jose Jimenez Alarcon
User avatar
xnview
Author of XnView
Posts: 43163
Joined: Mon Oct 13, 2003 7:31 am
Location: France

Post by xnview »

josei wrote:Hello

First of all, many thanks to all who answered my question.

Well with linepadding=1 the problem with the two extra bytes is now resolved.

But I have the second problem

The size on windows of a image (dicom) is 524288 bytes with 2.11 I got on Filesize this value but with 2.40 I get the following value 13293124

With a jpg file of 69635 bytes with 2.11 I got this value but now I get 13296832

I use the followings settings


load_option.Flags |= GFL_LOAD_SKIP_ALPHA;
load_option.Origin = GFL_BOTTOM_LEFT;
load_option.ColorModel = GFL_BGR;

I don´t know if there is any diference but I have a c function that modify the defaulf file selection dialog of windows to show a thumbnail, like xnview, and one of the fields is filesize...it shows the right file size.

Yours

Jose Jimenez Alarcon
Strange anyone has the same problem?
Pierre.
MaierMan
Posts: 78
Joined: Wed Aug 04, 2004 8:32 pm

Post by MaierMan »

xnview wrote: Strange anyone has the same problem?
Question is: how do you get the value?
something like ftell();
or maybe GetFileAttributesEx()?
Latter has some issues when computing the size the wrong way. But can not fully recall what was causing them...
have to look in my code archive...
(and this issue is most likely pre-vcs time so I dont have neigther CVS nor SVN history... Not sure If Ill find it :()
josei

Post by josei »

Hello

I work with C so Filesize is get from GFL_FILE_INFORMATION structure with the followinf call

gflGetFileInformation(_parc(1),_parnl(2),&info);

_parc(1): Name of the file
_parnl(2): -1 (index)

for dicom (no compressed files) you have the size on the header of the file...son there is no external calls

for other files I got the size from xnview

Yours

Jose Jimenez Alarcon
User avatar
xnview
Author of XnView
Posts: 43163
Joined: Mon Oct 13, 2003 7:31 am
Location: France

Post by xnview »

josei wrote:Hello

I work with C so Filesize is get from GFL_FILE_INFORMATION structure with the followinf call

gflGetFileInformation(_parc(1),_parnl(2),&info);

_parc(1): Name of the file
_parnl(2): -1 (index)

for dicom (no compressed files) you have the size on the header of the file...son there is no external calls

for other files I got the size from xnview

Yours

Jose Jimenez Alarcon
Do you have the same with all files?
Pierre.
josei

Post by josei »

Hello

I have the same strange results with all kinds of images...like bmp,tiff..etc

By the way I have modified my routines to use the function gflLoadThumbnail, with has a info structure too...and I get the rights values on Fliesize....any idea?


Yours

Jose Jimenez Alarcon
MaierMan
Posts: 78
Joined: Wed Aug 04, 2004 8:32 pm

Post by MaierMan »

What happens if you run this testcase program.
Its a console application which expects first argument to be the file ;))
(You'll propably need to set appropriate #pragma link)
(Maybe doing <iostream.h> inststead of <iostream> but anyway)


I can verfiy that output is correct with BCB6 and MSVC.NET 2003.
(Means GFL and WIN32API match and even the "bads" are ok)
But there might be issues with BCB5 series (IIRC)

testcase program

Code: Select all

#include <iostream>
#include <windows.h>
#include <libgfl.h>
#pragma link "b_libgfl.lib"

int main(int argc, char* argv[])
{
	OSVERSIONINFO osi;
	osi.dwOSVersionInfoSize = sizeof(OSVERSIONINFO);
	if (GetVersionEx(&osi))
	{
		std::cout << "WinVer: " << osi.dwMajorVersion << "." << osi.dwMinorVersion << "." << osi.dwBuildNumber << " (" << osi.szCSDVersion << ")" << std::endl;
	}
	if (argc != 2)
	{
		std::cout << "Wrong arg count" << std::endl;
		return 0;
	}
	gflLibraryInit();
	GFL_FILE_INFORMATION fi;
	GFL_ERROR err;
	if ((err = gflGetFileInformation(argv[1], -1, &fi)) == GFL_NO_ERROR)
	{
		std::cout << "GflSDK: " << fi.FileSize << std::endl;
		WIN32_FILE_ATTRIBUTE_DATA fad;
		if (GetFileAttributesEx(argv[1], GetFileExInfoStandard, &fad))
		{
			// ok, this will mess with files > 4GB, but using __int64 is too much for such a testcase :p
			std::cout << "Win32API: " << (fad.nFileSizeLow + fad.nFileSizeHigh * MAXDWORD) << std::endl;
			std::cout << "Win32API bad1: " << (fad.nFileSizeLow) << std::endl;
			std::cout << "Win32API bad2: " << (fad.nFileSizeLow + fad.nFileSizeHigh) << std::endl;
		}
		gflFreeFileInformation(&fi);
	}
	else
	{
		std::cout << "Failed to retrieve info" << std::endl;
		std::cout << "GFL: " << gflGetErrorString(err) << std::endl;
	}
	gflLibraryExit();
	return 0;
}
User avatar
Ithier
Posts: 47
Joined: Fri Nov 19, 2004 10:50 am
Location: Paris, France

Post by Ithier »

Hi,

Just a crazy idea :wink:, could it be that the value returned is the adress of the pointer to the data instead of the data ? (Perhaps because h and lib are not referring to the same versions of GFL).
josei

Post by josei »

Hello

Thanks to everyone who helps me. I don´t know why....but now every thing is working. :?: ...perhaps the lost post is in the way.


Thanks

Jose Jimenez Alarcon