-
You'd need to use some of the metadata flags for that, even if it is non animated, such as NoLocalPalette (FIDT_BYTE) = 1 and then put your palette in the metadata GlobalPalette (FIDT_PALETTE) instead of (or in addition to) the regular local palette.
2009-08-31 21:55:42 UTC in FreeImage
-
I'm using 3.12.0, but I need static lib under Windows. I guess the best solution I could find was to remove png.obj from the other static lib I'm using (with lib.exe), as their libpng is an older version anyway. It seems to work, but I wish there was a better way to link such that they both could be static and both could use their own copies of libpng, just in case the options in pngconf.h that...
2009-07-04 01:16:35 UTC in FreeImage
-
I recently updated some of my libraries a large project of mine uses and now when I compile, I get a bunch of errors like these:
FreeImage.lib(png.obj) : error LNK2005: _png_set_sig_bytes already defined in ToolkitPro1122vc71SD.lib(png.obj)
Neither FreeImage nor ToolKitPro need to really "talk" to eachother, but my application uses both pretty heavily itself. Is there a way to hide...
2009-07-02 06:13:00 UTC in FreeImage
-
I think it is pretty well documented that FreeImage does this. It is simply a speed issue with memory access.
You should be using FreeImage_GetLine to get the width (in bytes, included unused ones) of the row, not FreeImage_GetWidth
Of course, it is easier to just use FreeImage_GetScanLine in a loop to get individual lines as you go, instead of doing the math for each pixel access.
2009-05-05 22:59:46 UTC in FreeImage
-
Something must be wrong with the fread implementation you are using then, as read_proc/fread should return the number of elements read upon success, which is 1. It should not return the size of the elements or the total bytes read.
2008-01-15 18:09:18 UTC in FreeImage
-
I've noticed this before too. I think pixels are never more than 1 value off, and most are the same. I just figured rounding/compiler optimization difference with floating points probably was to blame.
2007-12-12 20:22:10 UTC in FreeImage
-
It looks well thought out, and very useful.
Adding bloat and slowdown for all the people who won't use it does seem to be somewhat of a drawback. I wouldn't worry about plugins where progress is difficult or impossible - you can still just throw out "0% here" and "100% here" and maybe fudge some 50% or other marks at least. It doesn't break anything to not have as much of fe.
2007-11-28 21:22:40 UTC in FreeImage
-
Kevin, this is not a matter of "it appears to work". VB (at least I am certain of VB6) does NOT support calling __cdecl functions, and without a lot of stack trickery, you are risking very certain memory corruption and crashes if you are using the callbacks from VB. FreeImage uses only __cdecl for the FreeImage_OutputMessageFunction typedef. I'm surprised you don't simply receive a...
2007-08-31 15:30:58 UTC in FreeImage
-
There is no detection, FreeImage is designed to use 10.3.9 and 10.4u SDK and compile to a universal binary which can only run on 10.3.9 or higher (10.4 is simply required for Intel at all).
2007-08-28 20:41:10 UTC in FreeImage
-
The recommended way would probably be to download the zip file from sourceforge, unzip it, and just go type "make".
I don't really know where "macports" gets the source from, but it may not be an official or newest copy if you do it that way.
2007-08-28 17:22:00 UTC in FreeImage
