Where can I find a resource on how to create a custom image format?

This topic is 4435 days old which is more than the 365 day threshold we allow for new replies. Please post a new topic.

Recommended Posts

For instance, I dont know how I would store the data of each pixel. I'm wanting to do this because I plan to create a custom format for an OpenGL application. Also, I'm using the C++ language.

Share on other sites
THe language doesnt matter....how you want to store the pixels is up to you since its your own format...a raw format does nothing but store the pixel, pixel by pixel. Something like a bitmap though has a header with info and stores RGB (though I think its BGR, plus alpha). Other formats may have encyption and or compress and lots of other goodies.

Share on other sites
Yeah. The problem is that I wouldnt know how to turn an RGB/RGBA value into an unsigned byte.

Share on other sites
Ummm....what do you mean? RGB... red, green, blue. 0-255, one byte each. So you could make a file format with 3 bytes for each pixel. 4 if you want RGBA

Share on other sites
Thanks for the info. For a second there, I thought you had to combine the r, g, b into one strange value (I'm thinking of something else though).

Share on other sites
C++ (it may be microsoft only, not sure) has an RGB() and RGBA() macro that takes 4 values and "converts" them into a long. there are also similar functions that can pull out the specific values from a long.

this doesn't answer your main question, but is a useful way to store / read the values.

Share on other sites
That's a Microsoft macro, and expands roughly into:

#define RGB(r,g,b) (((b & 0xFF) << 16) & ((g & 0xFF) << 8) & (r & 0xFF))

Share on other sites
Yeah, you can just save the RGBA values directly to a file, probably with the width and height and format (RGB or RGBA, and color depth) as well. You might also want to preclude everything with a few "ID" bytes, so you can make sure you're loading a valid image. So your format might look like this:

ID String
width height
RGB or RGBA
color depth
pixel data

of course, this will almost certainly be in binary format, so it won't actually look like the above. But you get the idea.

Take a look at fstream in the stl.

Share on other sites
Just don't do it.

There are lots of existing image file formats already, and one of them is likely to suit your needs just fine.

For example, there's JPEG for photographic lossy compression; PNG for pixel art lossless compression (with transparency) or paletted images; TGA for lossless images typically without compression but with full alpha channel, or paletted images; and DDS which supports pretty much any kind of uncompressed encoding you can think of (although only the DXT series of compression formats). There's TIFF to support storing pretty much any kind of bitmap data. There's PSD for storing multi-layered, tile-accessed complex image documents.

The benefit of using an existing file format is that you can view them in the Windows Explorer window; you can open them in Photoshop and change them around and save them out again; and you can mail them to your friends (or receive them from your friends) without any compatibility worries.

What possible reason could you have to create your own image file format, instead of using an existing format? Perhaps if you described to us what specific features you need of the file format, we could suggest an existing, well-supported file format for you to use instead of re-inventing the wheel.

Share on other sites
Unless you're developing some wickedly brilliant compression scheme I would have to agree with the above posts, existing formats have most of the major bases covered. In the end you'll either have an index value pointing to a color table for each pixel, or you'll have so many bits dedicated to various color channels per pixel. Even with compression it will stil have to be converted to an array of color values at some point, so I would save my effort for more interesting problems.

Share on other sites
Quote:
 Original post by Horatius83Unless you're developing some wickedly brilliant compression scheme I would have to agree with the above posts, existing formats have most of the major bases covered. In the end you'll either have an index value pointing to a color table for each pixel, or you'll have so many bits dedicated to various color channels per pixel. Even with compression it will stil have to be converted to an array of color values at some point, so I would save my effort for more interesting problems.

I concurr with both this, and the moderator's post, with one exception:
sometimes you've just gotta do things to understand how they work. I know it's easy enough to grab libpng or libgd or what have you, but for some people it's just not enough to read about how something works, but you just have to get your hands on it and know the raw feeling of what it takes to compress an image.

That being said, I used to do a lot of this kind of thing when I was playing around with compression years ago. It can be as simple as indexing color values, to run length encoded images to B&W transforms to fourier transforms; it's a good way of learning all of the various algorithms and mathematical steps of doing it, just don't fool yourself into thinking that they're any better than something that currently exists unless it really really is better (which is highly unlikely) and definitely if you're writing a game or something, don't use it.

So, to recap: unless you just want to experiment with image compression, you've really got no business writing your own image format. It only stresses yourself and others out, and the end result just isn't any better than anything on the market already.

Share on other sites
Yeah, I dont intend to make a format to beat all others, it's primarily just for learning.

Anyway, one more question. To store pixels, would I used an array of unsigned chars or unsigned ints? I've been told that using int was better, but I dont see why I would need a value greater then 255, and also ints take more space then chars.

Share on other sites
You can represent a single RGBA pixel as an unsigned int. "0xaarrggbb" will lay out (on x86) as "bb gg rr aa" in memory. It's sometimes faster to do operations by word than by byte, and it's certainly easier to write pixel-indexing code when an index of 1 means "the pixel one pixel in" rather than "the green component of the first pixel".