Freeimage update?
BlitzMax Forums/Brucey's Modules/Freeimage update?
| ||
| I just noticed that the latest version of FreeImage supports loading camera RAW file formats. This is a really useful feature as most professional photographers use this format, and I was wondering if you were planning to update the mod to the latest version to support it. |
| ||
| It's on my list of things to do. The Win32 integration work is a lot of effort though, which tends depress me somewhat, and therefore I put it off longer than I would normally for an update :-) (FYI, the Linux and Mac integration is simply a matter of compiling up the sources... it doesn't get much better than that. The Win32 build is not set up for static linking (into a Module), so a lot of hacking is required to persuade it to work - it's either that or a DLL, and I'd rather not.) |
| ||
| It turns out that RAW support is provided by libraw, which is LGPL. This is bad news for a statically-linked module, so for now I've disabled RAW support in the latest release until I decide the best way to go forward. Otherwise, the latest SVN contains a BaH.FreeImage using FreeImage 3.13 |
| ||
| You could wrap the source code instead, right? |
| ||
| I always thought raw would require an fwrite and a pixelcount * 4 bytes per pixel, but oh no... If both RAW and various tags of TIFF are "issue enabled" then perhaps Brucey, best solution for Swift's users themselves is giving them the ability to download latest version of official dll direct from freeimage so in future years they can keep up with image formats, proprietary stains and all. Another compromise I've used in past jobs is to keep lite weight with formats you statically support and add support for dll usage on top. |
| ||
| giving them the ability to download latest version of official dll direct from freeimage That's how it originally worked on Windows, before I got it compiling under MinGW. Now it seems that for everyone, I may need to go the way of the shared object - if it is to continue to support ALL the formats. Another compromise I've used in past jobs is to keep lite weight with formats you statically support and add support for dll usage on top. That's something else I've been toying with. Perhaps a FreeImageRaw module, which links to a small DLL with the LGPL code in it. Bloody incompatible licenses.... |
| ||
| I always thought raw would require an fwrite and a pixelcount * 4 bytes per pixel, but oh no... You'd think... But there's actually a lot more to RAW files than the name may indicate. On top of that, pretty much all camera vendors have their own proprietary implementation. It has a lot more information than just a plain bitmap though: with proper RAW editing software you can actually change the camera settings themselves after the fact (e.g. increase/decrease exposure, white balance, etc. to a MUCH greater level than you can with a normal bitmap of JPEG image. There's plenty of reasons that most professional photographers shoot exclusively in RAW. |
| ||
| I've added a new module - BaH.FreeImageExt - which adds RAW image support to FreeImage via a DLL/shared object. I've tested it on Mac and Win32 so far, and it appears to work as expected. There's also a small example which attempts to load a Nikon D70 raw image file. When loaded using normal FreeImage, it only loads a thumbnail. When loaded using FreeImageExt, it loads the full RAW image. A DLL is used because libraw is LGPL. Only in SVN for now, because both this and the main FreeImage module need some more testing before I can say it's all good to go... |
   |