Programming C, C++, Java, PHP, Ruby, Turing, VB
Computer Science Canada 
Programming C, C++, Java, PHP, Ruby, Turing, VB  

Username:   Password: 
 RegisterRegister   
 Which picture format?
Index -> General Programming
View previous topic Printable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic
Author Message
mirhagk




PostPosted: Mon Aug 16, 2010 3:45 pm   Post subject: Which picture format?

I have an idea for a project that I'm working on. The project is a voxel based raycasting game (well not really game, more like interactive environment). Anyways I have developed a method that allows each node of a sparse voxel octree to take up the space of a single rgba value (4 byte value). This way it can be passed into the graphics card with very little overhead. (much, much less than a polygon model of approx. the same detail).

That being said, the model could also be saved in this manner, as a simple raw picture file. But it'd be nice to save in under a compressed picture file format if possible, and simply load it in as a picture. Now the only issue is that I need the picture to lose NO data. Like converting from a 4 byte colour array to a picture and back again should not affect the individual colours at all (actually specifically the alpha value, which must have every bit be right, the rgb part of it could be off, doesn't really matter).

I know that .jpeg compresses it at a slight loss of data, even that slight loss is unacceptable for my uses. I think that .png does not affect the data, and allows for pretty good compression. Can anyone shed some light on this subject for me? I need to know which formats provide lossless compression, and which provides the best compression (The data is near random so it can't be based on reoccuring colours or whatnot)
Sponsor
Sponsor
Sponsor
sponsor
DtY




PostPosted: Mon Aug 16, 2010 7:34 pm   Post subject: RE:Which picture format?

There are two general categories for compression:

- Lossy: when data is compressed, some data is lost. A good lossy algorithm will do a good job at not removing any important data so you can't tell without looking really closely that anything was lost. Of course, "important data" depends heavily on the context. Jpeg is optimized for photographs, you've probably seen a jpeg from a line drawing or something, it looks awful, this is because jpeg is not designed for this sort of image, so it removes important data (and MS paint, the program responsible for most of these images, does not allow you to tweak the jpeg compression level and instead uses a really low level). There is also an audio format called speex (spx) that is designed to compress the human voice really tightly, but since it is designed for compressing speech, if you compress music with it, it is unlistenable.

- Lossless: when data is compressed and uncompressed the data you get back is *exactly* what you put in. Think zip. If you zip a text file, and it comes out with some letters missing, it's unacceptable. Again, compression is often geared towards specific purposes (for example, png is a lossless image compression that can get really good compression for line drawings, but is really awful for photographs), but no data is ever lossed, if it has trouble encoding something, instead of losing more data, it will create a larger file.

Unfortunately, all compression is based on patterns, so there is absolutely no way to compress near random data.

PNG is your best choice, don't worry about size. Unless you're working with photograph sized images, even uncompressed formats will be an okay size.

e; It is not compression, but there is another technique you can use to reduce the size of images, called colour mapping, but it only works if there is a small number of unique colours. What it does is places each colour used on a map, and then when describing the image data, it refers to the map instead of the actual colour.

PNG and GIF both support this, but only up to 8 bit maps (meaning up to 256 unique colours). If you have more colours than that, the saving process will map colours that do fit onto the closest matching colour in the map (it may create a colour that is inbetween two close colours that was not actually in the original).

GIF also supports multiple layers (this is how you get animated gifs), and each layer has it's own colour map, so you can use more colours by putting them on different layers. You might want to experiment with this, but I have no idea if it will get better compression than PNG without a colour map.
mirhagk




PostPosted: Wed Aug 18, 2010 7:37 pm   Post subject: RE:Which picture format?

thank you, I was thinking of using .png and I think I will use it. I understand that it will not compress it by much, but every little bit (or byte) counts:)

But upon further pondering I have decided to build this program in assembly (to try and make it run faster, as well as trying to learn more about assembly).

Thank you for your help
md




PostPosted: Thu Aug 19, 2010 6:58 pm   Post subject: RE:Which picture format?

You almost certainly won't gain any speed with assembly - any decent compiler is infinitely better at optimizing then you will likely ever be - but if your goal is just to learn... go nuts.
Display posts from previous:   
   Index -> General Programming
View previous topic Tell A FriendPrintable versionDownload TopicSubscribe to this topicPrivate MessagesRefresh page View next topic

Page 1 of 1  [ 4 Posts ]
Jump to:   


Style:  
Search: