problems loading file with crosscompiled code

[CorBee]

Hi,

I am developing a freeware application that uses 16bit/channel PNG files to do some image-processing for amateur astronomers. Ive setup the code in Linux (FPC3.2.2) and it works fine. I can load files and access the data easily, processing works fine too.

The code to load the PNG into memory looks like this:
Procedure LoadImagetoMemory(filename:string);
var  Ext:string;                                                         
begin
   ext:=ExtractFileExt(filename);
   if (ext='.png') then
     begin
      MemoryImage := TFPMemoryImage.Create(0,0);
      MemoryImage.Loadfromfile(filename);
     end;     
end;

memoryimage is earlier declared as MemoryImage: TFPMemoryImage;

In a button Click procedure I have this code:
....
  OpenPictureDialog1.Execute;
  if (OpenPictureDialog1.Files.Count = 1) and (FileExists(OpenPictureDialog1.FileName)) then
  begin
    ScreenImage.Picture.LoadFromFile(OpenPictureDialog1.FileName);
      LoadImageToMemory(OpenPictureDialog1.FileName);
 
  end;   

As stated this works perfectly on Linux but on windows the 1st call (screenimage.Picture.Loadfromfile(...)) does
work and the image gets displayed on screen. But the second call (loadImageToMemory) simply fails with a
"FILE NOT OPEN" error. Originally I did not have (since I do not need it) the call to screenimage.picture.loadfromfile but
I wanted to see if I could isolate the problem at least before asking for help. It looks as if the MemoryImage system after cross-compiling for windows does not work the same as in Linux.

I would like to hear how I can bypass this ? Ive also thought about using the BGRABitmap system, the TexpandedBitmap seems
a good candidate but I have not seen code that uses it for a 16bit PNG usecase like mine.

kind regards
Cor Berrevoets


*************************************************
RegiStax Free Image Processing Software
http://www.astronomie.be/registax
*************************************************

​TeensyBat Bat Detector
https://github.com/C...nsy_batdetector

 

[KodeZwerg]

  OpenPictureDialog1.Execute;
  if (OpenPictureDialog1.Files.Count = 1) and (FileExists(OpenPictureDialog1.FileName)) then
  begin
    ScreenImage.Picture.LoadFromFile(OpenPictureDialog1.FileName);
      LoadImageToMemory(OpenPictureDialog1.FileName);

You can setup in options that the open dialog only returns file that exists, that way you can eliminate all your upgoing checks and write it like...

Code: Pascal  [Select][+][-]

1. if OpenPictureDialog1.Execute then
2.   doSomething...

[KodeZwerg]

    ScreenImage.Picture.LoadFromFile(OpenPictureDialog1.FileName);

At that point the image is already in memory... ?!

[KodeZwerg]

Procedure LoadImagetoMemory(filename:string);
var  Ext:string;                                                         
begin
   ext:=ExtractFileExt(filename);
   if (ext='.png') then
     begin
      MemoryImage := TFPMemoryImage.Create(0,0);
      MemoryImage.Loadfromfile(filename);
     end;     
end;

I do not know what TFPMemoryImage is, but you create here a memoryleak each time you call that method!

[CorBee]

Hi,

Ive added the code to load a file through the picturedialog only to test things. The file gets loaded once in this setup only so a memoryleak is not a worry or the issue. The issue is that in windows loading in a memoryimage fails and in linux (with the same code) this works fine. 

Thanks for having a look but the issue is not due to memoryleaks etc.

cheers
Cor

[MarkMLl]

We sympathise, but you'd make it far easier if you posted a complete program we could compile and test.

MarkMLl

[dbannon]

CorBee, you say "crosscompile" ? Are you cross compiling or are you just taking your code to over to a windows box where you have another Lazarus install and compiling here ?

If the later, you should be able to narrow down the problem a bit, is it the MemoryImage.Loadfromfile(filename) thats going wrong ? Sure the copy of the image you have on the Windows box is not corrupted ?

Is it the same version of FPC/Lazarus ?  Have you read the docs for TFPMemoryImage  ? It might behave differenly on different platforms. I cannot find it but I guess you know where it is. If its a FP rtl function, you will not be able to step through it (without recompiling the RTL with debug info) but you can still read the code.

If you are really crosscompiling, then maybe its time you setup a Lazarus install on the Windows box (wash your hands carefully afterwards).

Davo

[CorBee]

Hi Mark, Davo,

I was crosscompiling on Linux, so my linux machine was setup to crosscompile for windows. Ive taken the resulting exe to a windows machine and ... the problem I had (when testing it under wine or in a VM with Windows running from linux) was still present. I will setup the windows PC with lazarus and try if compiling from there results in a working exe file. If so, that seems to point more towards an issue with TFPMemoryImage due to crosscompiling. If the same problems exists still its an issue with TFPMemoryImage under windows. TFPMemoryImage is not a new part of freepascal/lazarus (ive used the same many years ago when I worked on this) but the documentation is rather minimalistic. But in my earlier usage I found this to be a rather easy way to get 16bit data from a png or tiff file that can be easily extracted. No need to write (or use) older code from the time I was programming with Delphi.

Thanks for responding, I will report back

Cor

[CorBee]

Hi,

I have solved it ... in my original code I had several writeln commands that showed up nicely when developing in the Lazarus IDE. But those same writeln commands made the code fail under windows. I found out the hard way by just adding a simple Memo on the application and writing to that, suddenly I saw that it did load in to the memoryimage but it failed shortly after in another routine.

So after commenting them out ... the whole thing works as planned. So no problems with any of the code but just a major difference between Win64 and Linux in the way writeln is
working. I dont need writeln in this project so I will just use a logger to keep track during debugging.

If anybody knows why win64 fails because of this (using a crosscompiler from Linux) I would like to hear that. Thanks
for the help !

cheers
Cor

[dbannon]

Yeah, Lazarus apps normally don't have a console, writeln writes to the console.  There is some way to declare a lazarus app as having a console but I cannot remember ...

Better to use debugln(), it writes to the console on Linux and its output can be captured to a file on windows. Sadly, you need to remove all writeln() in your code, except, of course ones writing to a file.

Good that you have solved the bigger problem !

Davo

[CorBee]

Not to difficult to replace the writelns. I am going to catch this maybe with debugLn but I also want my testers to directly have a look at a debug-log so Ill provide a space where the debug can be followed.

cheers
Cor

[howardpc]

Yeah, Lazarus apps normally don't have a console, writeln writes to the console.  There is some way to declare a lazarus app as having a console but I cannot remember ...

Code: Pascal  [Select][+][-]

1. {$apptype console}

[CorBee]

Thanks for that 

[Bart]

Yeah, Lazarus apps normally don't have a console, writeln writes to the console.  There is some way to declare a lazarus app as having a console but I cannot remember ...

Menu->Project-Project Options->Compiler options->Config and Target->unselect the "Win32 gui application (-WG)" checkbox.
(On the main toolbar there is a button to directly acces Compiler Options, and Ctrl+Shift+F11 should also open Project Options, so no need to go through the main menu)

Bart