pixmaps and pngloader up to 16bit
BlitzMax Forums/BlitzMax Programming/pixmaps and pngloader up to 16bit
| ||
| Hi Mark, I know this isn't a new topic, but being that blitzmax shows to be an excellent platform to develop apps of all kinds aside from the games, it would be just fantastic, if you were to expand the pixmap implementation and libpng use to support 16bit or even float, if you were at it. It's use for asset creation and even tools beyond games altogether, it would certainly widen the appeal of Blitzmax to many developers. I'm a big fan and love it dearly, but I'm a little afraid to mess around with the related modules. I had a quick look and saw that it should be not too terrible to add, but figured it would be in much better hands, if you were to take a look. I'm sure you have plenty of things to do and deal with and don't mean to impose. I just know I should at least mention the thought to you. I'm currently writing a little tool to create "material spheres" for sculpting apps and other realtime render solutions, which is getting very nice, but it's screaming to have 16bit export options. At the same time it would be very encouraging to me to dwell even deeper into that kind of app development. Thanks in advance for thinking about it and already and always for what you've done! |
| ||
| Interestingly, FreeImage doesn't support 16-bit depth for png export, although it does support export types of RGB16 and RGBA16, which I presume at the things you are looking for. The problem with BlitzMax's TPixmap, is that it's built for display (which tends to fall into the 8bpp range), and not necessarily manipulation, so loaders tend to be fixed to work with Pixmap. A library like FreeImage also supports high dynamic range imagery (float, double, 128-bit, RGBAF, etc), which is useful in certain areas. I dunno how interested Mark would be in adding support to load/save that Pixmaps don't currently support. |
| ||
| Personally I think features like this would really boost bmax as a development platform, but at the same time would draw focus away from the main goal of a game development platform... I develop all kinds of stuff with bmax beyond games, but at it's heart, as brucey said regarding pixmaps being tuned for display, bmax is really about game development and not really applications as such. I think it would be a great place for a module to slot in, perhaps bring with it some pixmap manipulation tools, and a converter between 16bit and 8bit pixmaps so you could load an image, manipulate it at 16bit, pull off a 8bit version to display (in game, or preview, etc.) then save the 16bit version again... basically what I use Freeimage for but I don't care too much about the extra bit depth :0) |
| ||
| Well, the curious thing is that the included libpng has all the functions available. It's actually the internal pixmap and the defines and parameters sent to libpng that would need the "silent" addition to support 16bit. Uhm...pixmaps being the really tricky part, of course. In the libpng use of the pngloader module you can simply switch the argument for bit depth (8) to 16 and it wants to save a 16bit png (successfully I might add, just that it's content is confused, of course). I'm certain it ain't really "simple" when it comes to the pixmaps, but the pngloader mildly whispers to allow access to more of what libpng has to offer. Then again, I'm just carefully asking. No drama, if it's not on the agenda. I'll always dig it for the games and I'm sure I can somehow fight my way through dealing with what ever raw image format libpng wants and instruct it properly myself, I hope. Thanks for bouncing in so quickly already, guys! |
| ||
| If it's internally supported then perhaps you could duplicate the TPixmap type and then create an extension for it that overrides the stuff that doesn't work in 16bit with stuff that does? As you said it can't be that simple of course :0) but I think that could be the easiest starting point, especially if you already see spots that are 16bit friendly with a tiny tweak here or there... I'm not so great at overrides and extensions myself (I always bork the syntax in bmax for some reason... too many languages dancing in my head) but perhaps brucey might have a tip or 2 on how to override some of the internals since I think freeimage takes over the pixmap routines when it's included... |
| ||
| Hmmm, that's a good idea! For some reason I wasn't even thinking about copying to write an extension, but literally to intrude and extend the existing one, hahaha. Which is percisely what scared me. Therefore; THANKS, that's a liberating idea right there! :) However, I hope that Mark will stumble upon this little thread and give it a quick thought. Something tells me, he might find that it's only a brief exercise to ramp pixmaps and the pngloader/saver up to more of its potential. Just for clarity, here's what I'm doing and where I specifically miss 16bit support... glReadPixels(....,GL_RGBA,GL_UNSIGNED_BYTE,snapshot.pixels) snapshot = YFlipPixmap(snapshot) 'I had to laugh that it even has a function! <hihi> SavePixmapPNG( snapshot,...) I would love to use GL_RGBA16F of glReadPixels to write into a 16bit Pixmap and SavePixmapPNG were using libpng's existing 16bit options that are dormantly sitting in bmax and are happily waiting to be used. :} |
   |