BlitzMax can't open Indexed Coloured images?
BlitzMax Forums/BlitzMax Beginners Area/BlitzMax can't open Indexed Coloured images?
| ||
| Why can't BlitzMax open images that useses Indexed Colours? If you create a normal BMP file and switch to "Indexed Color" (I'm using Photoshop) BlitzMax won't be able to open it and it's causing a lot of troubles. :/ I have about a 100 BMP files, all in Indexed Color mode and they're completly usless now. Is there a quick fix for this?, or will I have to spend weeks modifying the standard modules? |
| ||
| I know this isn't helpful, but why are you using BMP's? That's a lot of space being used up for only 100 images. |
| ||
| It's a long story, basically the data for my game is from an older game that uses BMP files and they're all in Indexed Colours. |
| ||
| Why can't BlitzMax open images that useses Indexed Colours? Because they border on useless for games? They haven't really served a useful purpose in about 15 years. Videocards no longer operate on indexed color images, so they have to be converted before uploading to the videocard anyway. From an artistic point of view, indexed colors has no other effect other than to restrict the artist. From a techncal point of view, PNG, JPG and JPeg2000 probably offer better image quality with comparable or better filesize. So I'm guessing that BRL saw no purpose in supporting a format which restricts the artist and gets converted anyway. A quick fix? Batch convert them to PNG? |
| ||
| Converting them is not an option. There's about 500 different types of game data my engine can load and each of them have about 100 BMP images, the users would have to convert every time they wanted to try some new data and it would probably mess up the original data. |
| ||
| Bmax isn't the app to use for this purpose then. |
| ||
| Oh well, cheers anyways! :] |
| ||
| I'm not entirely following your scenario. Initially, I thought you were remaking an old game, and would be responsible for distribution of the new game, including data. From what you're saying now though, am I right in assuming that you're writing a new game/application but that you either won't be distributing new data files or that people can provide their own? So it has to be a code-only solution? I think Noel Cower wrote a DevIL module some time ago, that might possibly load the format. Perhaps Brucey's modules ( there is a forum specifically for those ) might have something too. I'll have a look on my hard drive too. I wrote my own wrapper for DevIL at one point too, but I'm not sure if I still have it. EDIT: Brucey has a bah.freeimage module. That should be able to do it. |
| ||
| Yep, I was just compiling FreeImage and it seems to be working. :] Cheers. |
| ||
| I was just taking a look at the BMP file format specification, it is not particularly complex. In fact it makes a format like ILBM/IFF look complicated. You could quite easily write a BMP reader to handle planar/indexed images and simple output the results of your loading to a pixmap in 24 or 32-bit truecolor form. All you really need is a translation/interpretation between indexed color and truecolor as you load it. |
| ||
| I dont understand this. Direct-X 7 can safely work with indexed colors, OpenGL also, and even on B3D it works. Saying "it has no use", it's just absurd. Try comparing a PNG with 256 colors (or even 16!) to the same PNG saved with 16 millions colors (even if it uses only 4 or 5); the size difference is enough to support indexed colors use - of course, when there's no loss in quality. |
| ||
| i think we just got lazy and just saved as default bmp's so we never bothered that a 24 bit 16 colour file would be way bigger than a 16 colour one |
| ||
| It's a 10 year old approach, times have moved on and now pretty much all graphics cards are 16 or 32-bit color, or even 64 to 128-bit floating point color. Indexed colors are just not very useful anymore, very limiting - why restrict to 256 colors when you can have whatever color you want? PNG does a pretty good job of compressing truecolor without quality loss. If you really want to use indexed it's likely that you're trying to save storage bytes. That's the ONLY reason, because it's useless until it is converted to 24-bit color to be displayable. So write your own BMP loader that converts indexed to 24-bit. |
| ||
| Direct-X 7 can safely work with indexed colors, OpenGL also, and even on B3D it works. Nope. Internally, they're converted. Try comparing a PNG with 256 colors (or even 16!) to the same PNG saved with 16 millions colors (even if it uses only 4 or 5); the size difference is enough to support indexed colors use - of course, when there's no loss in quality. I'm pretty sure indexed PNG's already load fine, hence my suggestion to batch convert. I stand by the "useless" generalization though because the difference in size you refer to only exists when your images are uncompressed. If the amount of hard drive space they use - or the download size of the game - was remotely important to you, you would compress them. With a decent compression algorithm, they're the same size. |
| ||
| Just a thought, but have you tried using an add-on image loader like Brucey's Freeimage.mod module? It supports many formats: GIF, BMP, DDS, EXR, HDR, ICO, IFF, JNG, JPG, JPEG 2000, KOALA, LBM, Kodak, MNG, PCS, PBM, PGM, PNG, PPM, Photoshop (PSD), Fax G3, SGI, RAS, TARGA, TIFF, WBMP, XBM and XPM. Several of those (GIF, IFF, LBM) are always indexed color, so at least in principle it's possible that it also does index BMP's... |
| ||
| I stand by the "useless" generalization though because the difference in size you refer to only exists when your images are uncompressed. Sorry, but I disagree. A compressed PNG with 256 (or 16 colors) gets even smaller than a compressed 16 bit or 24 bit PNG, no matter how good your compression algo is. Of course, on memory, they are all converted to 16/24/32bits - but on disk (and on download size) it makes a difference, specially when working with 1024x1024 textures or higher. If you tell me that a b/w picture wont benefit to be saved as a grayscale image (which IS a 256 indexed color image, using just gray palette), then, I cant continue this debate anymore :P |
| ||
| Well whether or not Index Colored images are useless or not, I'm forced to used them. And I'm still having some problems with them I'm afraid. :/ All images using Indexed Colours are always really dark, a lot darker than they should be. I've made an example of this that you can get over at: http://www.wikifortio.com/784139/IndexColorTest.zip You'll need Brucey's bah.freeimage module. And don't tell me to just convert the BMP, because that's not an option for me. :P |
| ||
| Just for the record, BMax's BMP loader can handle:- 1 bit monochrome BMPs 4 and 8 bit indexed colour BMPs 24 bit BMPs 32 bit BMPs with alpha It doesn't, however, load RLE compressed BMPs. I'm pretty sure this is the real issue here and it *shouldn't* be too much of a mission to add RLE decompression to BRL.BMPLoader. |
| ||
| You're probably right Yan, I've noticed that some Indexed colour BMPs do load just fine using the standard BMax's BMP loader. (Including the BMP in my test) Got any tips on how I could load RLE compressed BMP? >_> |
| ||
| Freeimage should be able to load/save RLE compressed bitmaps. |
| ||
| But Freeimage loads all Index Coloured images too dark. I've made an example of this over at: http://www.wikifortio.com/784139/IndexColorTest.zip |
| ||
| Indexed images are worthless, unless your main concern is harddisk space. Hardware does not support it, so it will at least be a 16bit texture, normally 32bit. Its possible that freeimage reads it correctly but your "comparision application" applies color management profiles to it when loading it. |
| ||
| Indexed images are worthless, unless your main concern is harddisk space. Just because that may not of much worth to you, I'd hardly say it's worthless. There are other implications of this inability to load RLE compressed (apparently) images as well: for example, if you create any program that allows the user to supply their own media, or something like a paint program, it sure would be nice if you can read the particular file that a user may present without just blowing up. |
| ||
| But Freeimage loads all Index Coloured images too dark. Seems there was a problem converting 4-bit images. I've patched the SVN version (rev 442). |
| ||
| Just because that may not of much worth to you, I'd hardly say it's worthless. They are not much worth as game textures for anything else than saving disk space. again, when beeing transfered to the GPU, the indexed stuff will vanish, they will either be 16bit or 32bit textures again like BMP and PNG. Just with the difference that you don't have used the full 32bit for color gradients so the filtering will suffer banding effects very likely unless you have a specific toonish style or similar. That is what I meant with that comment and thought the clarification should be enough. indexed colors in todays world mainly make sense for GIF + web nothing else supports them anymore, especially not hardware accelerated 3d graphics like BlitzMax |
| ||
| indexed colors in todays world mainly make sense for GIF + web nothing else supports them anymore, especially not hardware accelerated 3d graphics like BlitzMax True. But good luck writing something like a decent paint program if you can't load them reliably. There's other uses for BlitzMax than just writing games... |
| ||
| There's other uses for BlitzMax than just writing games... Shhh... I'm not sure you are allowed to say things like that! |
| ||
| @Hezkore - I'm not sure if you're still interested in this now that Brucey has fixed the Freeimage problem, but anyway, information about the RLE compression algo can be found here... http://msdn.microsoft.com/en-us/library/cc230530.aspx |
| ||
| Actually, thinking of that, there ARE some uses besides games where you'd want to support indexed images, such as if you're writing a paint/drawing package. |
| ||
| There's other uses for BlitzMax than just writing games... Actually no BM is only for game development and related editors from the official comments from BRL on that topic. Show me anyone who is going to accept a common application that only accepts ASCII in the path names. 75% of the mankind has letters outside the ASCII range. |
| ||
| Brucey, I'm still having problems with Images being too dark in FreeImage. Edit: Everything is working now, the SVN version works great. |
| ||
| So many people thinking BlitzMax is just for writing games. I've moved all my tools from BPlus ... been a bit of a slog, but it all works, and is blisteringly fast in comparison. I work in a studio that literally churns out pixel animation... all indexed 8bit pngs (mobile games). BM not supporting 8bit images is a nuisance, but file format readers/writers are pretty easy to write compared to the amount of manual work involved in hand carving hundreds of sprites into spritesheets every day. My BM tools read and write FLC files, and when needed I call a command-line util to run 24bit pngs into 8bit indexed pngs. So I beg to differ: BM is *great* for tools. |
| ||
| You could write your own blitz routine to convert the 24bit png's into 8'bit, probably? I second the notion that BlitzMax is good for applications, I mean it's got MaxGui which right away suggests applications/tools. I'm planning to write some graphics/image processing software with it. It's good for whatever you want to do with it, it's just that its `intended` purpose is somewhat focussed on game creation. |
| ||
| "it's just that its `intended` purpose is somewhat focussed on game creation." I 100% disagree with that as I've said before. There's very little "out of the box" that screams "make a game with me". ;) |
| ||
| its guilty by association very few ami blitzers wrote well known utils b2D/b3D games bias through and through addressed via b+ in taking out the 3D part and adding windows gadgets widgets and what nots bmax is b+ with go faster stripes |
   |