Since images can’t contain other buffer types then bytebuffer, how are all those formats in the image class supported? You have to pack them manually into several bytes each or something? Couldn’t find any info on this, and just want a heads up before doing some stuff like that, thanks. 
That’s one reason I didn’t implement get/set pixel for the 16 bit formats for the first release of that. Big or little endian was the main thing that could be a potential issue.
Ah. I suppose saving/loading raw float arrays will do then. I’m making huge terrains and need real good precision. Getting some “minecrafty” terrains cause the values are packed too tight.
http://www.jamtlandoutdoors.se/images/dist2/precision_loss.png
Luminance16 might be your best bet. I’d be happy to add getPixel/setPixel for that (would only take 15 minutes including working out whether it’s big or little endian and adding the tests) but since I’ve still no idea what’s happening with get/set pixel it’s not really worth my time at the moment…
There is also Luminance16F but that uses floating point in the data so no idea how bad or not it would be to encode/decode.
No, no problems, thanks for the info :D. I just wanted to know if there was some way of doing this before deciding. Gonna use either raw buffers or AWT “short images” for storing the heightmaps.
@androlo said:
No, no problems, thanks for the info :D. I just wanted to know if there was some way of doing this before deciding. Gonna use either raw buffers or AWT "short images" for storing the heightmaps.
I'd avoid AWT when possible, as that would break Android deployment.
@androlo said:
Since images can't contain other buffer types then bytebuffer, how are all those formats in the image class supported? You have to pack them manually into several bytes each or something? Couldn't find any info on this, and just want a heads up before doing some stuff like that, thanks. :)
Small but maybe important correction... You are actually unpacking when putting something larger into something smaller like a ByteBuffer. Packing is the other direction. If you want to shove 4 bytes into an int then that's packing.
I mention that because it explains why ByteBuffer is a nice base to have since for most things it is the "lowest common denominator"... you can easily unpack things into it and pack things out of it again.
For example, (and you may already know) you can make a ByteBuffer look like a variety of other things with asShortBuffer(), asFloatBuffer(), etc... a similar pattern can be used for more obscure formats.
@androlo: You can now directly access pixels of an Image by using the ImageRaster class. For your example, you can use Luminance32F to store heightmap information with high precision. Note that there’s no way to write this data to disk though … Not unless you use BinaryExporter.
@pspeed
Thanks. I was more concerned about how to use them in combination with image formats then how they work in general. If I use Format.RGBA16 to store a short array or buffer as an image, for example, but I have to use a byte buffer, how do I make the engine/ogl read and then write the values as intended. Are there are engine or ogl methods for that (to flag and sort out the byte order etc.)?
@Momoko_Fan
Thanks. Gonna look into that.
@androlo said:
@pspeed
Thanks. I was more concerned about how to use them in combination with image formats then how they work in general. If I use Format.RGBA16 to store a short array or buffer as an image, for example, but I have to use a byte buffer, how do I make the engine/ogl read and then write the values as intended. Are there are engine or ogl methods for that (to flag and sort out the byte order etc.)?
I may not be fully understanding the problem... but if you want to use a ByteBuffer as short... then create a ByteBuffer and then set the byte ordering (with order()) and then get is as a ShortBuffer with asShortBuffer(). Then just deal with the shorts... it is modifying the underlying ByteBuffer and that's what you would use for anything requiring that.
You'd still have to pack your 4-bit color components into a short... but you wouldn't have to worry about byte ordering or byte indexes.