FreeImage -> PF_RGBA8888 pixmap?

BlitzMax Forums/Brucey's Modules/FreeImage -> PF_RGBA8888 pixmap?

ima747(Posted 2010) [#1]
I'm using free image to load my pictures and do a resize since the internal resize functions are ugly ugly and my source pictures can be anything (jpeg, png, etc. etc.) of any size. Anywho I need to get back a pixmap in PF_RGBA8888 format and everything I'm trying is not working. What's the proper path to get back a PF_RGBA8888 pixmap directly from freeimage?

convertToType(PF_RGBA8888) throws up
FreeImage: FREE_IMAGE_TYPE: Only 24-/32-bit dib can be converted to type 6.

I'm sure I'm just missing something obvious


Brucey(Posted 2010) [#2]
convertToType() doesn't use BlitzMax pixel formats for parameters, unfortunately.

However, you might want to try convertTo32Bits() instead.


ima747(Posted 2010) [#3]
As always, thanks for the response Brucey!

Done some more poking into exactly what/where/how I'm getting differences.

on mac (intel) if I do convertto32bits() (which I was doing previously) I get type 6 (PF_RGBA8888) on the returned pixmap format (32bit BIG endian RGB with alpha) which is what I need. Great, job done.

On Windows (vista x64 if it matters) convertto32bits() gives me type 5 back... which I think is PF_BGRA8888 (32bit LITTLE endian RGB with alpha) and still needs a conversion... dunno why the mac is giving me big endian on intel (haven't tried on my PPC but I would expect big endian there...) perhaps it's an OS flag in the FreeImage library for better compatability between PPC and intel macs?

either way I need a way to get big endian 32bit out of free image across platforms if possible.


ima747(Posted 2010) [#4]
A little more background. the reason I want to get freeimage to give me an RGBA8888 pixmap is because I've found in rare occasions that I can't pin down because it's too random my program will crash when converting a pixmap through pixmap.Convert(PF_RGBA8888). I've done more poking and it happens at somewhat random points durring the out[]=in[] copy in brl.mod/pixmap.mod/pixel.bmx in converttostdformat(). this is a straight buffer to buffer copy so it would make sense that one of the buffers is going bad during this process... my suspicion is the garbage collector is causing it to be moved. If I put a GCCollect() right before my pixmap.convert() it tends to crash much sooner. I wrapped my pixmap.convert() with GCSuspend() and GCResume() and I haven't gotten a crash yet, even when I throw GCCollect() right ahead of the suspend. The crash was happening on 1 intel mac and my x64 windows machine, but not on another identical intel mac. Identical hardware wise, they're all running different software, i.e. different memory footprint, therefore different firing on the GC.

So, 2 questions
1) I would still like to use FreeImage for the RGBA8888 conversion because I think it's likely to be faster, and my pictures already go through it for some scaling etc. so it's easy. is it possible to do that or is converto32bit() and it's OS difference the closest I can get.

2) Is it possible that pixmaps returned from FreeImage are able to be moved around by the garbage collector in a way that a pixmap created in bmax natively would not (is there some sort of lock?) or do you suspect this is a problem with how bmax handles pixmap conversion and I should post accordingly in the bugreports forum?


Brucey(Posted 2010) [#5]
on mac (intel) if I do convertto32bits() (which I was doing previously) I get type 6 (PF_RGBA8888) on the returned pixmap format (32bit BIG endian RGB with alpha) which is what I need. Great, job done.

the pixmap that is returned by TFreeImage is just a static pixmap based on the internal data. Generally, that data is like this :
				?win32
				format = PF_BGR888
				?macos
				format = PF_RGB888
				?linux
				format = PF_BGR888
				?


As far as I am aware, internal image data on Mac uses the same endianness on both PPC and Intel - someone can correct me if I'm wrong.

Note, that because it is a static pixmap, the next time you modify the image, or the image is GC'd the related pixmap data will be "undefined".

I can't see why you would have issues calling Convert() in BRL.Pixmap. I've never had any issues with it, on any platform.


ima747(Posted 2010) [#6]
The issues with converting pixmaps happens when the garbage collector trys to move the pixmap data while it's converting. If you disable the garbage collector (GCSuspend() does the trick) then there's no problem. It only happens when I'm really thrashing the memory (tons of pictures mostly quite big, along with lots of lists, etc etc., doesn't happen in a simple sample because there's not enough memory getting abused). So my current workaround is to just wrap pixmap.Convert() calls with GCSuspend() and GCResume(), since doing that I've had no conversion related problems on any platform.

A related problem I get on rare occasions is FreeImage will fail to load or resize a picture. It only happens again, in low memory situations when I've been thrashing memory. My work around for that is by monitoring the memory usage through the garbage collector again. On different platforms the max limit before I start seeing problems changes drastically but it's fairly reliable so I just make sure when I'm getting near the ceiling I look for stuff I can clear out before trying to load more. If you have time to take a look at how FreeImage handles itself when it fails to complete an action due to not enough memory that would be great, but I'm functional now. And, yet again, these kinds of things ONLY happen when I'm abusing the hell out of the memory, any normal/polite program is probably not going to thrash memory like I am unless they've made some typos :0)