FreeImage_GetFileTypeFromHandle Deletes Objects?

[colin glenn]

On recommendation:

Well, that worked, now to work around another issue

Colin, you would probably get more exposure if you post the new issue in a seperate thread. Also, as FreeImage is a bit of a minority interest, it might be worth posting the function prototype and the code which you are using. HTH.

Backstory:

I wanted to write some type of wrapping around an object memory handler to deal with converting raw data into a FreeImage_BitMap and likewise, convert a FreeImage_BitMap into raw data of whatever type I selected for the output. There is valid strange reasons for this, example, dealing with a file which contains multiple packed images in bitmap format and you want to convert each of them into png format. The results so far is a class which takes a pointer to a block of memory, writes that block of memory to an INSTANCE array of bytes, and has handler's for reading and writing to that block of memory. So far, sounds good. The module (memloader.bas) also has wrappers for the calls FreeImage makes to gain access to this block of memory, each is rather simple in nature:

FUNCTION FreeImage_MemoryReadData(BYVAL buffer AS DWORD, BYVAL dwSize AS DWORD, _
            BYVAL dwCount AS DWORD, BYVAL fiHandle AS MemoryLoaderSystem) AS DWORD
    FreeImage_MemoryReadData = fiHandle.ReadData(buffer, dwSize, dwCount)
END FUNCTION

One of the things I needed to do, was to redefine one of the FreeImage DECLARES:

DECLARE FUNCTION FreeImage_GetFileTypeFromObject _
   LIB "FreeImage.dll" ALIAS "[email protected]" ( _
   BYREF FreeImageIO, _                 ' FreeImageIO *io
   BYVAL MemoryLoaderSystem, _          ' fi_handle handle
   OPTIONAL BYVAL LONG _                ' int size FI_DEFAULT(0)
   ) AS LONG                            ' FREE_IMAGE_FORMAT

So that I could call the function. It all works once. Then crashes because somewhere, the Object's DESTROY is being called.

So, is it me or FreeImage?

PS: In the ZIP, the line to decomment, if it isn't already, is:
nFileType = FreeImage_GetFileTypeFromObject(fiIO, memHandle)

PSS: Another reason for trying to do things this was was to have it a bit extensible by being able to have multiple memory handler objects active.

(Updated the attachment with working example. 2/9/2009)

[Chris Holbrook]

Then crashes because somewhere, the Object's DESTROY is being called.

Are you sure that is what is happening - if so, you could place code in the Destroy method to show from where it is being called. I use this macro for said purpose:

macro mShowStack(debugmsg)
    macrotemp s, i
    dim s as string
    dim i as long

    s = funcname$ + " : " + debugmsg + $crlf
    if err then s = s + $crlf + "ERROR = " + str$(err)
    for i = 1 to callstkcount
       s = s + $crlf + callstk$(i)
   next
   ? s
end macro

BTW -and this may help somebody along the line, if not yourself - I have also noticed that calls to an object's methods can go t*ts up even if the object is valid, if invalid addresses have been passed on the stack, for example, a function returns a pointer to one of its own its own local variables, this is used in a call to a method which not-so-mysteriously crashes in the function call. Initial but wrong diagnosis - object not valid.

[Chris Holbrook]

Colin, where is the FREEIMAGE.INC file?

[colin glenn]

Ahh, foo. hmm, dunno if I can upload it here because it's Jose's, ...

[colin glenn]

Comment out that include and these three declarations should be used in memloader:

TYPE FreeImageIO
    Read_Proc     AS DWORD    ' pointer to the function used to read data
    Write_Proc    AS DWORD    ' pointer to the function used to write data
    Seek_Proc     AS DWORD    ' pointer to the function used to seek
    Tell_Proc     AS DWORD    ' pointer to the function used to aquire the current position
END TYPE

DECLARE SUB FreeImage_Unload _
   LIB "FreeImage.dll" ALIAS "[email protected]" ( _
   BYVAL DWORD _                       ' FIBITMAP *dib
   )                                   ' void

DECLARE FUNCTION FreeImage_GetFileTypeFromObject _
   LIB "FreeImage.dll" ALIAS "[email protected]" ( _
   BYREF FreeImageIO, _                 ' FreeImageIO *io
   BYVAL MemoryLoaderSystem, _          ' fi_handle handle
   OPTIONAL BYVAL LONG _                ' int size FI_DEFAULT(0)
   ) AS LONG                            ' FREE_IMAGE_FORMAT

And the program will compile.

Oh, right, you also need FreeImage.DLL in the same folder, ...

[José Roca]

The function is expecting a file handle, and you are passing a pointer to a class. This can never work.

[colin glenn]

I was afraid it would be something strict like that, drat, foiled again.

Hmm, does it really need to be a pointer if I'm supplying the pointer elsewhere, that is, can it be a number which I translate into an index into an array?

[José Roca]

It really needs to be a pointer, and more specifically, since FreeImage is written in C, a pointer to a FILE structure:

TYPE FILE
   ptr      AS ASCIIZ PTR   ' char *_ptr
   cnt      AS LONG         ' int   _cnt
   base     AS ASCIIZ PTR   ' char *_base
   flag     AS LONG         ' int   _flag
   file     AS LONG         ' int   _file
   charbuf  AS LONG         ' int   _charbuf
   bufsiz   AS LONG         ' int   _bufsiz
   tmpfname AS ASCIIZ PTR   ' char *_tmpfname
END TYPE

A pointer to this structure is returned by C functions that open a file, such fopen.

[Chris Holbrook]

If you are following this story, the Freeimage headers are at http://www.jose.it-berater.org/smffo...p?topic=1488.0

You need to be enrolled on José Roca's forums to download them...

[colin glenn]

I think the memory operations of FreeImage are a bit simpler than that, one of the examples defines the structure like this:

typedef struct {
          char * data;
          char * ptr;
          long   size;
          int    mode;
        } Memory_IO_Handle;

And just in the FreeImage distribution I found this:

typedef struct fiio_mem_handle_s {
    long filelen,datalen,curpos;
    void *data;
} fiio_mem_handle;

/* it is up to the user to create a fiio_mem_handle and init datalen and data
 * filelen will be pre-set to 0 by SaveToMem
 * curpos will be pre-set to 0 by SaveToMem and LoadFromMem
 * IMPORTANT: data should be set to NULL and datalen to 0,
 *            unless the user wants to manually malloc a larger buffer
 */
FIBITMAP *FreeImage_LoadFromMem(FREE_IMAGE_FORMAT fif, fiio_mem_handle *handle, int flags);
BOOL FreeImage_SaveToMem(FREE_IMAGE_FORMAT fif, FIBITMAP *dib, fiio_mem_handle *handle, int flags);

So now I see why it was causing the Object to reset, it tampers with the passed item itself.

[colin glenn]

Wait, my bad, I mixed matched which header files was going with which sample program, ...

And yes, I am enrolled on Jose's forum.

[colin glenn]

It pays to carefully read what the sample programs are doing with which functions, and matching the header files with the proper sample programs.

And after much study and reading of the code, I boil it all down to a very small routine:

FUNCTION FreeImage_LoadDIBFromData(dwData AS DWORD, dwLength AS DWORD) AS DWORD
' assumption: dwData points to beginning of block, dwLength is actual length
LOCAL pDib      AS DWORD
LOCAL hStream   AS DWORD
LOCAL dibType   AS LONG

    hStream = FreeImage_OpenMemory(BYVAL dwData, dwLength)
    IF ISTRUE hStream THEN
        dibType = FreeImage_GetFileTypeFromMemory(BYVAL hStream)
        IF dibType >= 0 THEN _
            pDib = FreeImage_LoadFromMemory(dibType, BYVAL hStream)
        FreeImage_CloseMemory hStream
    END IF
    FreeImage_LoadDIBFromData = pDib
END FUNCTION

[colin glenn]

Updated the attachment just because.

The memory loader has a weirdness which I suspect is from FreeImage itself, seems it don't handle the various dozen or so GIF format images I have lurking about my hard drive. Looks like it's taking a RGBTRIPLE and reading it as a RGBQUAD or something. At this time, seeing as I will never be dealing with a memory object of GIF format, I'm not chasing this weasel down it's hole, but I will post a query about it over on the FreeImage support board.

* replace GIF Format with PALETTE format images, ...

** wrong again, added function to use FreeImage_Load and it's apparently SetDIBitsToDevice to blame. Either that or FreeImage is returning the info wrong, ...

[colin glenn]

I figured I'd post my resulting code http://www.powerbasic.com/support/pb...ad.php?t=39856

Solved the palette distortion problem, was passing the SetDIBitsToDevice the INFO not the INFOHEADER, displays palette images properly now.

Also included StretchDIBits to the program, and the various menu selections work as expected.

This was a nice learning experience for me. Don't trust PB objects with outside applications.
:dang:

[Cliff Nichols]

Just because I often find the situation of "Quantum Leap" and "To fix what ONCE went wrong", you might want to rephrase your comment of

Don't trust PB objects with outside applications.
:dang:

into

Don't trust outside applications with PB (objects or otherwise)
:dang:

For me, PB seems to get it RIGHT when another language may take "SHORTCUTS" (not to say it does not "Uuuuuusuallly" work, but when it does not, then where to look????

When in doubt, research the language of choice, if a shortcut or assumptions were used, and if none found then check if possibly the same in PB (most the time you will not get that far)

And I must add before doing ANY of that, verify not some mis-use, or abuse, or mis-understanding of "As Documented"

[Bern Ertl]

I posted some freeimage code years ago. Not sure if it is germane to what you were trying to do here:

http://www.powerbasic.com/support/pbforums/showthread.php?t=23483

[colin glenn]

Just because I often find the situation of "Quantum Leap" and "To fix what ONCE went wrong", you might want to rephrase your comment of

Overall, it may have been PB at fault, FreeImage uses stdcall to get the procedures it needs to read from the handle, and when the PB function returned, it may have "released" the object, who knows. It's not something worth chasing down and figuring out a workaround when there's so many other ways to accomplish the desired results.

I posted some freeimage code years ago. Not sure if it is germane to what you were trying to do here:

That was something I did look at and play with, and it helped me learn something about what was going on "behind the scenes" when FI was used in acquiring data from another device. Seeing as I am able to deliver the whole data chunk to FI intact, and I had no need to buffer the output when saving the data, I went with the option to use the memory functions for the conversions. Thank you very much for posting some sample code.