It's not very different but the the end result does not work yet :( There are crashes that I have not yet figured out.

What works fine in MacOS now is dynamic linking to libtiff like in Linux. It's not enabled by default though
since I guess not many Mac users have libtiff installed (contrary to Linux situation).

I am using the newest version of Vampyre Imaging on Windows 7 with Lazarus 1.6.4. (32 bit).

When adding the package to my project and trying to compile, I get the following errors:

lazarus.pp(154,1) Warning: Library libtiffpack-win32.a not found, Linking may fail !
lazarus.pp(154,1) Error: Can't open object file: libtiffpack-win32.a

Obviously, Lazarus cannot find the libtiffpack-win32.a located in \Extras\Extensions\LibTiff\Compiled.

I have tried the LCLImager Demo and it is working there. I saw that there ";..\..\..\Extras\Extensions\LibTiff\Compiled" is added to the "Compiler Options > Libraries (-FI)" while the package itself has no link to the Compiled folder at this point. However, when adding ";..\..\..\Extras\Extensions\LibTiff\Compiled" to the package compiler options, it is not working, too. Or am I missing something at this point?

When creating a new project and adding ";..\..\..\Extras\Extensions\LibTiff\Compiled" to the project options, it is compiling and Lazarus finds libtiffpack-win32.a. When omitting this, I get the error. But also the IDE is not compiling anymore, there I get the same error "Can't open object file".

I think the package is missing a link or include to the Compiled folder at some point. However, I have not enough expertise to fix this on my own. Can you help me?

Great library!

Have you planned a TIFF support also for FPC on Mac OS?

And what have to be done to do that? Isn't the LibTiff compilation also working on the Mac? Or is it very different to Windows or Linux?

Hello,
I would like to convert a png image with transparency in a bitmap but with the possibility to choose the color for the background (replacing transparency). What is the easiest way to do this?

thanks for every help

Hi,

yes the library is not really thread safe -
most of the library core is from 2003 & 2004 with no thread safety in mind.

Of course, it's been sitting in my todo list for a long time now.
There are several suspect places mostly related to image loading and saving,
rest of the library should be quite ok.
What I'm mostly worried about is that used 3rd party libs like OpenJpeg and libtiff
would cause problems.

Anyway, improvements to thread safety are planned but that "time for the library" is still very limited :(

Hi Galfar,

about a year ago, we detected that the library seems not to be thread safe.

We had 2 threads decoding hundreds of jpegs in a row, which always resulted in unpredictable crashes.
We found some code positions, where global variables were used, which caused the crash.

We fixed it by serializing the decoding calls.

There were some plans in testing the introduction of threadvars for these variables, but since the bug was solved, there was no need from "above" for this anymore ;)
Sadly, i lost the documentation of the code positions which caused this.

In general, are their any plans to make the library thread safe by yourself?
I am asking now, since you seem to have time for this awesome library again ;)

No Problem..
Thx for your work. We really appreciate it.  :)

Precompiled LibTiff for FPC has been finally added to Imaging for Win32 and Win64.
In Linux it's now using dynamic linking to libtiff since there it's already installed on most systems or simple to install where not.

Thanks for the patch, finally applied it.

Imaging now has up to date repos also here:
https://bitbucket.org/galfar/imaginglib
https://github.com/galfar/imaginglib

Apologies for bumping, but I would like to join