Some things strange with bcc 5.0

[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

[xnview]

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?

[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]

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;
}

[xnview]

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...

[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.

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:

LinePadding
Pad for a pixels line (For example, a value of 4 allow a line padding on 32bits).
Default value : 1

[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

[xnview]

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?

[MaierMan]

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]

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

[xnview]

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?

[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]

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;
}

[Ithier]

Hi,

Just a crazy idea , 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]

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