Unfortunately I was not able to open and display the test image ...
... able to load several large images ...
Have you tried LazPaint? Made by circular, is really fast.Thanks for the hint. I already tried LazPaint and LazView. It surprises me that LazPaint comes with its own file open dialog and said dialog already fails to open the image with a EOutofMemory error (TBGRAWinBitmap.RellocBitmap: Windows error 87).
Hello Timur Born,Thanks for the warm welcome and the links, I will read through them.
Welcome to the forum.
This simple demo shows how to load and show an image using Lazarus, try it:I am still trying to wrap my head around it. When I compile it as is then the window stays empty (no controls at all). Do I have to create the controls in the form editor and rename them according to the code? When I add controls it changes the code to fit in the new controls first.
LazPaint is not made for images larger than 256 Mb. It would be interesting for me to know though when the problem happens and whether it is a crash or just an error message.Have you tried LazPaint? Made by circular, is really fast.Thanks for the hint. I already tried LazPaint and LazView. It surprises me that LazPaint comes with its own file open dialog and said dialog already fails to open the image with a EOutofMemory error (TBGRAWinBitmap.RellocBitmap: Windows error 87).
The error with the 3 gb file happens when the preview is supposed to be created in the load dialog, it does not crash and another image can be chosen/opened afterwards.If image loader tries to load whole image into memory, then you should check if your compiled Lazarus application is 32-bit, or OS is 32-bit.
[DEBUG] Name com.canonical.AppMenu.Registrar does not exist on the session busMaybe LCL trying to get a service on a Linux system.Have you looked into https://github.com/galfar/imaginglib ?Sorry, I missed this part. But yes, I already looked into its compiled demos and tried LCL Imager. It does not support TIFF, so I had it open a PNG version of the 1.35 gb image. It is faster that LazPaint, but still far too slow in opening the preview and image.
It is possible to point directly to a library using the external keyword. That's the simple but I guess you can do that only if you are sure the library will be available.Thanks for the hints and extra information. Via its installer Nomacs installs OpenCV as as dll files of about 16 mb and 28 mb respective file-size. That's okish, but the whole of FastStone IV (likely Delphi) fits into the 16 mb size, including language files and plugins. FastStone launches a bit quicker to draw the window frame, but it's not faster until you reach the point where you can really use it. Long launch times is one thing that hampers ACDSee (and its Quick View module is limited is functions).
Otherwise it is also possible to statically link an object file (I never tried it personally). Here is the doc on external:Is there an advantage to doing this?
You can have more control over the dependency to the library. You need for this code that loads the library and retrieve the pointers to the procedures.Is the load/unload the main advantage? It could be used to unload libraries like LibRaw when they are not needed (no raw files to be processed).
...
On the other hand, you can choose when to load/unload the library, do something else if the library is not present, etc.
Is the load/unload the main advantage? It could be used to unload libraries like LibRaw when they are not needed (no raw files to be processed).There is the load/unload advantage. This can reduce the startup time and memory usage as you may not need to load all libraries. Another advantage is that you can look for the library file in the hard drive and load the one you prefer. I use that on Linux to get the best fit:
...you can look for the library file in the hard drive and load the one you prefer. I use that on Linux to get the best fit:Nice 8)
https://github.com/bgrabitmap/bgrabitmap/blob/master/bgrabitmap/linuxlib.pas
Dummy question: Is the whole library compiled into the exe when it is statically linked, I thought that only the parts being used are?I suppose if the linker can sort things out.
I am not against dynamically linking, but I recently installed all MSVC redistributables via a single installer and it installed 24 different versions. Even with that I am sure one of the next installers is going to ask me to install some of it again. >:DYes, relying on installed things on Windows is not great either in my experience. I prefer to supply the Dll next to the Exe if I can.
The load/unload parts sure has its charm, depending on how taxing loads/unloads are during runtime.The taxing happens anyway. Either on startup, when loading the image, or maybe when the application is idle.
One of the main reasons why you see me writing here instead of just enjoying user lala land is that I am really getting tired of all the unresponsiveness of desktop apps on expensive modern hardware. I keep throwing money at the problem, but still far too much time is spent on twiddling thumbs (watching animated circles/balls/"not responding") while resources are either unused or abused.I am sure we are many here to agree on that. It would be great that companies spend more time optimizing things rather than make the brand new thing.
It is worth mentioning that the QT based Nomacs viewer is very fast at viewing these large files, maybe even faster than anything I tried yet. Even only using a single-thread opens the displays the 3 gb TIFF file within 3 secondsAre you sure that whole 3GB of data are loaded in 3 seconds? That would render to 1GB per second which is very rare even with fastest M.2 SSDs. I would guess that for fast preview many tiff strips were skipped. For example, your preview window is 800x600 and your tiff image is 8000x6000. From that info and from info about tiff strips height in pixels, and from knowing the number of cpu cores available in your system, you can build a list of strips for multithreaded strips reading by prioritization of loading each n-th stip first to populate your preview window first, and then loading the rest of the strips when user thinks that all of it is already loaded. I am not aware of tiff image format details, so maybe you can also optimize loading of a single strip, by not loading all strip data at once.
Are you sure that whole 3GB of data are loaded in 3 seconds? That would render to 1GB per second which is very rare even with fastest M.2 SSDs. I would guess that for fast preview many tiff strips were skipped. For example, your preview window is 800x600 and your tiff image is 8000x6000. From that info and from info about tiff strips height in pixels, and from knowing the number of cpu cores available in your system, you can build a list of strips for multithreaded strips reading by prioritization of loading each n-th stip first to populate your preview window first, and then loading the rest of the strips when user thinks that all of it is already loaded. I am not aware of tiff image format details, so maybe you can also optimize loading of a single strip, by not loading all strip data at once.Indeed, the TIFF structure may help to do that. It depends how it was saved. The file can organized as strips or as tiles and if that's the case, you can for example extract only the tiles that are being displayed (zoom) or skip strips (unzoomed).
From that info and from info about tiff strips height in pixels, and from knowing the number of cpu cores available in your system, you can build a list of strips for multithreaded strips reading by prioritization of loading each n-th stip first to populate your preview window first, and then loading the rest of the strips when user thinks that all of it is already loaded. I am not aware of tiff image format details, so maybe you can also optimize loading of a single strip, by not loading all strip data at once.Worth mentioning that I have not seen any image viewer load any image type multi-threaded (per single file). I may have seen 2 thread for TIFF once, but it's possible that one thread was just busy with the GUI (despite nothing but image loading happening). Nomacs at least uses multiple thread for thumbnail creation (one thread per file/thumbnail that is).
As far as I understand the 32-bit .obj files cannot be used in 64-bit applications (and would thus not be able to handle 3 gb files)?Right, but that are libtiff object files and header translation are from 2007. Nothing stops you to make new libtiff object files for both 32-bit and 64-bit. Remember that 3 GB limit is just a speculation because of 32-bit limits and assumptions that whole file is loaded into memory at once. It may be something else. Clever 32-bit application should be able to handle almost unlimited image size at cost of speed.
Worth mentioning that I have not seen any image viewer load any image type multi-threaded (per single file). I may have seen 2 thread for TIFF once, but it's possible that one thread was just busy with the GUI (despite nothing but image loading happening). Nomacs at least uses multiple thread for thumbnail creation (one thread per file/thumbnail that is).Well, link I provided discusses possible speed improvements for tiff reading. One of them is multithreaded strips reading. It's up to you if you want to try it or not.
Reading the whole file(s) into memory is absolutely preferred for smooth operation without lags and judder.I was not saying that you should not load the whole file into memory. I was saying that you could first read every n-th strip (depending on preview window size) to show super fast preview to the user, and then read all the rest of the strips. If you wish you can also use multithreading (if I remember the linked discussion well - some developers said that it does speed up loading), but it is not a must. This is just a theoretical discussion. Final decision is fully yours.
So for the time being I will concentrate further research on OpenCV and ImageMagick.There is OpenCV Lazarus wrapper here: https://github.com/t-edson/LazarusOpenCV
I am not sure if the extra work needed to use current implementations of these libraries and (re)learning of Pascal are worth the effort over just going the C(++) route then.Quite reasonable from time needed point of view. However if OpenCV 2.4 is good enough, or quick testing of COM lib and ActiveX controls of ImageMagick goes fine, you might end up in pascal train after all. ;)