-
il_tiff.c::iSaveTiffInternal() is hard coded to use LZW compression when the IL_USE_COMPRESSION hint is set. However, if LZW compression is not enabled in the linked version of libtiff then the subsequent call to TIFFWriteScanline() will fail with an error relating to LZW not being found, and a valid TIFF will not be created.
Coincidentally, I discovered this issue while working in Windows...
2009-06-18 21:46:31 UTC in Developer's Image Library
-
I'm convinced this is a legitimate bug, and since I didn't get any responses I've gone ahead and opened a bug report and posted a patch here:
https://sourceforge.net/tracker/?func=detail&aid=2808435&group_id=4470&atid=104470.
2009-06-18 14:46:30 UTC in Developer's Image Library
-
For more info see forum post https://sourceforge.net/forum/forum.php?thread_id=3304599&forum_id=13560.
In summary, il_io.c::ilSaveImage() does not call iRegisterSave() until after checking all default types, which prevents the overriding of these default types with a registered save function.
The attached patch fixes this issue.
2009-06-18 14:44:55 UTC in Developer's Image Library
-
The attached patch fixes Bug 1505635 where TIFFs were always saved as RGB even if they only contained a single color channel.
2009-06-18 14:32:03 UTC in Developer's Image Library
-
The ilTypeFromExt() function in il_io.c does not check for "raw" extension and consequentially does not return IL_RAW. See the attached patch to fix this bug.
2009-06-16 15:20:02 UTC in Developer's Image Library
-
In il_io.c::ilSaveImage(), why is it that the call to iRegisterSave() comes after all calls to all the nominal ilSaveXYZ() functions? It seems like this prevents me from overriding the save functionality for an already supported format. For instance, I would like to write my own save function to override the built-in one for .raw files, but this seems to be impossible.
On the flip side, in...
2009-06-16 13:54:22 UTC in Developer's Image Library
-
This patch addresses the issue in Bug 773686.
Luminance BMP files are currently saved as BGR rather than straight grayscale, resulting in files that are legitimate BMPs but are 3 times larger than they need to be. This patch checks for IL_LUMINANCE format and in that case generates a BGR32 grayscale palette and leaves the data as IL_LUMINANCE format, rather than not generating a palette and...
2009-06-12 13:09:53 UTC in Developer's Image Library
-
This isn't a bug in a functional sense, but it could be considered a bug from a performance point of view. il_files.c::iReadLump() implements a loop to copy a single byte at a time from a lump to a working buffer and executes a conditional test after each read. This makes the code needlessly slow, and should be rewritten to execute the same logic in a more efficient fashion. From the SVN logs,
2009-06-09 21:40:25 UTC in Developer's Image Library
-
This isn't a bug in a functional sense, put it could be considered a bug from a performance point of view. I noticed that writing binary PNM's took a lot longer than I expected. Examining the code in il_pnm.c::iSavePnmInternal() I noticed that the problem was due to repeated calls to iputc() to write out each byte, rather than a single call to iwrite() to write out the entire image. By...
2009-06-09 17:30:01 UTC in Developer's Image Library
-
In il_pnm.c, ILstring FName is always assigned to NULL. In iSavePnmInternal(), this causes logic which checks the filename extension to not complete correctly, thus the PNM type is always assigned to the default value of Type = IL_PPM_ASCII. This bug appears to have been introduced in SVN r1310. The attached patch eliminates the problem.
2009-06-09 14:17:01 UTC in Developer's Image Library
