i know... there is this rock solid libjpeg from the independent jpeg group. but: it is fairly huge, a complete overkill for my smaller game projects. the code size is not ignorable, this adds some 80 kbytes or so to my app. what i am searching for is either a small, TINY jpeg reading implementation or a custom lossy compresssion lib. i have no problem converting my data beforehand. optimally it would come with a single header and a single c(++) file. so one just needs to add these two to one's project and thats it. (besides, i call such very usefull, small libs "single header libraries") i want something similiar like TARGA in terms of simplicity and code complexity. (by the way: if you compress a TARGA file with bzip2, you get nearly png - compression rates. so no need for libpng, if you store your lossless images in an data-archive compressed with bzip2) i know - lossy image compression is much more complex than just lossless TARGA, but maybe someone here knows any library that can do lossy image compression with low code complexity? it must not compress better or equal than jpeg, just something in the same range. so someone here has a tiny, small wavelet / tinyjpeg or something code?

Theres some standalone PNG loading code (with compression) here which you might wnt to use/look at.

80 kbytes? Is that a typo, or are you developing for a platform with limited memory like a cell phone or PDA? If not, why are you worrying about a measly 0.08 mb?

IMHO, the 80k that JPEG and the 65k that PNG add to my executable is outweighed greatly by the megabytes I save by using these compression techniques..
(You can strip quite some stuff you won't need (like compression, special data chunks) from those libraries using the config-files)

@s1ca: fine. but: i want cross-platform portability. i do not want to code for every possible platform interfaces to the native libs. so far, i plan to port my game to win32, linux and osx. that means: 3 different interfaces... so i would rather like to have a nice, plain ansi c(++) code that has not a single platform dependency (just decompressing memory buffers)

@s1ca, smit: thanks for pointing out, i will look at this prefilter. but: i'm rather fine with my compress tga with bzip2. it compresses ( i have run some tests) for abstract line drawings even better than png. png is better on real world images, though, but only slightly ( 5-10%)

@doctorsixstring & dabono: you are right, 80kbyte is not that much. sorry for the - besides embedded systems - rather vain argument. but what still counts: i need to link another additional library. that means:
* porting hassles (need to compile / install lib on target platform)
* static linkage ? dynamic dll ? different code generation modes?
i spent countless hours to remove unresolved externals error messages just because of libraries not matching together (because they were compiled against different runtimes etc..)
* some libs just wont compile into a static library. for example openAL - i had to alter the source code manually to make a static linking one.

so much hassle. and here kicks in my wanted "single header - single c(pp) file principle": just add that to your makefile & project and you are done. whatever mode you compile your code, it will just work.
thats what i love about most boost libs: they are just header files. i do not have to link against anything.

Quote:Original post by herc
so much hassle. and here kicks in my wanted "single header - single c(pp) file principle": just add that to your makefile & project and you are done. whatever mode you compile your code, it will just work.
thats what i love about most boost libs: they are just header files. i do not have to link against anything.

Ah, that's a much better reason! I remember using DevIL a while back when I was working with C++. I'm not sure how much larger it will make your executable, but I remember it being pretty easy to get going, and it is very powerful.

Good luck!

Quote:Original post by lonesock
Well, neither of these 2 links are exactly what you want, but:

Hamed's small JPEG Library implements the (supposedly) most commonly used subset of the JFIF.

This Image-SCZ code shows a simple (lossy) processing step to run on an image, to then have it compress well with standard lossless compression algorithms.

wow! thanks for the links! that scz-compression lib is exactly what i want. low code complexity, just 6 files!