Jump to content
  • Advertisement
Sign in to follow this  
ilwG

Pinto, a new image format

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

If you intended to correct an error in the post then please contact us.

Recommended Posts

Advertisement
Text-based image formats, like the PPM/PGM/PBM family used by Netpbm or XPM, make sense only if they are editable by hand. XBM files, with binary pixels packed into hexadecimal digits, are only marginally editable; your file format, with run length encoding, is strictly machine only. If you give up the only benefit of text-based file formats, there is no reason to accept appalling feature limitations like 6-bit colour, a choice of ten hardwired image sizes, no transparency, etc.

Share this post


Link to post
Share on other sites

Lorenzo,

Did you read the README?

There are other benefits to a text-based format other than being able to edit the image by hand. With Pinto, I can easily embed images in my source code like this:

char *heart = "aww2000;00%F454i636g818ejclb?25cjehgfidkbm9o7q5s3u1^&9?Idd?25?Ej";

char *bitmapFontLetterK = "2#E3b2g3a4f395f385g375h365i355j345k335l325m315n8o7p8o?a4?i5?q4?y4?G4?O4?W485g@1a5a5e3b4e3c2^";

It also allows me to embed images in plain text files, which I will use in a future proj
ect.
Pinto images, even in their text format, are smaller than PNG images for the types of images it's designed to encode. The README also states that you can make Pinto smaller by running it through a standard compression function library like zlib or gzip.

6-bit color is only per the red, green, and blue values, so an individual color is actually 18-bit, which is plenty for old school game graphics.

I'm not sure where you got "ten hardwared image sizes", but that's not true. Pinto can encode any arbitrary image sizes.

You said "no transparency", but also not true. Pinto can encode images with transparent pixels, just no pixels that are partially transparent. Again, this is plenty for my use cases, such as bitmap fonts and old school game graphics.

Pinto is obviously not for everybody, but it satisifies my needs, and I'm happy with the way it came out. I share it in case it can be a benefit for somebody else.

I'd also like to point out that it's very high quality code. The "Quality" section in the README explains:
- Compiled with gcc's -Wall -Werror and -Wextra.
  Compiles with 0 warnings.
- Many unit tests guarantee everything works correctly.
- gcov and lcov is used to make sure we get as much coverage as possible.
  Current coverage is 100% branch coverage.
- Valgrind is used to look for memory leaks and memory corruption.
  There are 0 memory leaks or errors reported.
- Compiles cleanly against C89, C99, and C11 standards.
- All code is documented with doxygen comments.
- All functions are reentrant.
- Contains no third-party code, written entirely by Jeremiah.

Thanks,
Jeremiah
 

Share this post


Link to post
Share on other sites

I think it's a neat idea and fun. Looks like the "10 image sizes" thing came from seeing the code for a shortened header.


Yes, I'm sorry, I found the ten sizes represented as 0-9 in the decoder and I didn't look further. Avoiding misunderstandings due to hasty source-diving is one of the reasons why launching a file format requires a specification, not only an implementation.

Regarding the application to embedding images in source code and in arbitrary text files, the usual solution is layering Base64 encoding or a similar generic mechanism over traditional file formats. This has several advantages: decent and predictable size (original file size multiplied by a constant factor), reduced implementation effort (multiple established solutions for both layers are usually available), abstraction (any binary data can be embedded, not only images), flexibility (you are ready to load traditional non-embedded images without compromising their file format), interoperability with other tools using the same file formats and the same text encoding (common practical case: HTML data URIs).

For embedding data into programs, tools that generate a piece of source code from a generic binary file are even easier to write; it's very likely that some automated build step that does something with each asset is needed in any case.

Share this post


Link to post
Share on other sites

achild,

 

Thanks! It's nice to hear somebody else thinks it's neat. :)

 

 

Lorenzo,

 

No worries.

 

All your points are valid, and I agree with them all. :)

 

I made Pinto to test out an idea I had - mixing RLE with the Painter's Algorithm - which turned out well.

 

I also wanted to try and make a very tiny image format for my upcoming projects. I considered Base64 encoding PNG, but Pinto turned out to be quite smaller. You can see some comparisons here, where I compared pinto against png base64 encoded.

https://github.com/GeekHorse/Pinto/blob/master/examples/RESULTS.txt

Pinto was up to 70% smaller for the types of images I'll use, and about 40-50% smaller for the others, which is pretty neat.

 

Also, although I'm a fan of libpng and zlib, I dont generally trust the quality or security of most projects. I didn't want to worry about bugs or security problems in png/zlib, and updating my projects. So I wrote Pinto to be very high quality, and extensively tested, so I have much more faith in it not having a buffer overrun or such that could be used for nefarious purposes.

 

Thanks for taking a look at Pinto and sharing your thoughts!

Share this post


Link to post
Share on other sites

I made Pinto to test out an idea I had - mixing RLE with the Painter's Algorithm - which turned out well.

I also wanted to try and make a very tiny image format for my upcoming projects. I considered Base64 encoding PNG, but Pinto turned out to be quite smaller. You can see some comparisons here, where I compared pinto against png base64 encoded.
https://github.com/GeekHorse/Pinto/blob/master/examples/RESULTS.txt
Pinto was up to 70% smaller for the types of images I'll use, and about 40-50% smaller for the others, which is pretty neat.


The compression tests turned out very well; your idea seems good.

I think the right niche for this experiment is becoming a PNG replacement (or at least a PCX or GIF replacement) with significantly better compression: you should abandon the ASCII constraint and minimize file size with brute force compression of image data and with more compact headers.

Share this post


Link to post
Share on other sites
Sign in to follow this  

  • Advertisement
×

Important Information

By using GameDev.net, you agree to our community Guidelines, Terms of Use, and Privacy Policy.

GameDev.net is your game development community. Create an account for your GameDev Portfolio and participate in the largest developer community in the games industry.

Sign me up!