XnView Software

Various discussion boards for XnView and related products
https://newsgroup.xnview.com/

Some things strange with bcc 5.0

https://newsgroup.xnview.com/viewtopic.php?t=2990

Page 1 of 1

Some things strange with bcc 5.0

Posted: Sun Jul 24, 2005 7:08 pm
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

Re: Some things strange with bcc 5.0

Posted: Mon Jul 25, 2005 9:30 am
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?

Posted: Mon Jul 25, 2005 12:09 pm
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

Posted: Tue Jul 26, 2005 6:26 pm
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;
}

Posted: Wed Jul 27, 2005 1:49 pm
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...

Posted: Wed Jul 27, 2005 3:40 pm
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

Posted: Wed Jul 27, 2005 4:24 pm
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

Posted: Wed Jul 27, 2005 4:32 pm
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?

Posted: Wed Jul 27, 2005 4:57 pm
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 :()

Posted: Wed Jul 27, 2005 6:24 pm
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

Posted: Thu Jul 28, 2005 10:12 am
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?

Posted: Thu Jul 28, 2005 4:39 pm
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

Posted: Thu Jul 28, 2005 7:44 pm
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;
}

Posted: Fri Jul 29, 2005 7:40 am
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).

Posted: Sat Jul 30, 2005 3:12 pm
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
All times are UTC
Page 1 of 1

Powered by phpBB® Forum Software © phpBB Limited