new PNG to ILBM converter for Amiga, MorphOS, Linux, FreeBSD, Haiku and Solaris

[TCH]

I've just released my PNG to ILBM converter.

There's some basic usage examples. All of the converted images are converted from this image: http://oscomp.hu/depot/ferrari.png
With the exception of Amiga, which converted a pre-shrinked version of this image. (Due the limited memory in my A500+, it wasn't able to deal with a HD image.)

The converter supports resampling, quantizing and dithering to any bitplanes, used by the Amiga, including EHB.

For example:

png2ilbm ferrari.png ferrari_ehb.iff -w=320 -d -bp=ehb

(I show the result pictures converted back to PNG, to make them viewable from browser, but there are also links to the IFF files.)


(http://oscomp.hu/depot/ferrari_ehb.iff)

The converter also supports hi-res/laced pictures:

png2ilbm ferrari.png ferrari_8hril.iff -w=640 -bp=8 -hr -il -d

(http://oscomp.hu/depot/ferrari_8hril.iff)

If there is a need to convert a picture which can only use certain registers, then the others can be preserved:

png2ilbm ferrari1.png ferrari_5pr.iff -d -bp=5 -pr=0-7,17-19

With this line, a 5-bit picture is converted from the original, but colour registers 0-7 and 17-19 are preserved, thus the image uses only 21 colours.
(If the target bitplane number is EHB, then the preserved registers will extended to the upper 32 imaginary registers too, since if e.g. register 11 is unusable, then register 43 will be unusable too.)


(http://oscomp.hu/depot/ferrari_5pr.iff)

It's possible to override colour register during quantization. These registers will be also preserved during the quantization, but then they will be used during the colour replacing.
It can be used for partial colour adds (for example if the picture can use the registers used for other purposes, but cannot overwrite them), but also can be used to quantize to a fixed palette.

png2ilbm ferrari.png ferrari_c64.iff -w=320 -d -bp=8 -srl=c64-136.pal

This picture uses the Commodore 64's 136 coloured palette.


(http://oscomp.hu/depot/ferrari_c64.iff)

To use override from CLI, use the "sr" switch, the "srl" is to load the override list from a file. The format for them is identical: register:colour,register:colour,register:colour...

All of the generated pictures uses 24-bit palettes, but the converter can forced to convert them to 12-bit ones. The non-AGA Amigas are able to show the 24-bit palettes, but they only use the top 4-bit, which are not colour-correct shrinking, since for example $e1 will be $e, but in reality it should be $d ($e1 is much closer to $dd than $ee).
So, with the "f4b" switch the converter will colour-correctly shrink all the colours, then extend them again (also colour-correctly). By this the non-AGA machines will show the colours without brightness shifting.
However, since the quantizer works on 24 bit and the shrinking happens after the palette quantization, it can produce collosions, which can be more worse, than a non-correctly bright picture. (E.g. both the colours "3f89b1" and "4590a9" will be "4488aa" and the final image will use less colours.) So, use with care.

Binaries can be downloaded the for all supported platform from there: http://bgafc.t-hosting.hu/png2ilbm.html (The uncompressed binaries are weigh 'round 60-70 kB on every platform.)
Currently supported platforms are Amiga, Linux, Haiku, FreeBSD, MorphOS and Solaris on x86 and PPC architectures (Amiga is 68k of course). Further platforms (OSX, OS4) and archs (PPC64, Sparcs) will be supported, whenever i'll get there.
On AROS the build is failed, the log is also on the download page, if someone can tell me what is the problem, don't hesitate.
The quantizer eats up a lot of memory (around 7-800k), so on the Amiga, at least 2 MB RAM is recommended. With 2 MB of Chip RAM, there should be no problem about converting 320x200@24 pictures. (My A500+ managed to convert them during the tests, with only 2 MB of Chip RAM.)
If there are plenty of RAM (cca. 16 MB), then even HD pictures can be converted on the Amiga. (Well...slow water washes the coast, a HD picture can take much hours for a pure 68000.)

The binaries are standalone, they don't need external libraries on any platform, with the exception of the pure 68000 and 68020 Amiga versions which are needs mathieee*.libraries for floating point calculations. The 68020+68881 version don't needs FP libraries, but naturally it needs an FPU.

Well, have fun and don't forget to report bugs. :P
The binaries contains the detailed manual about everything, but if there are questions, then ask them.

[pandy71]

Originally Posted by jsr

All of the generated pictures uses 24-bit palettes, but the converter can forced to convert them to 12-bit ones. The non-AGA Amigas are able to show the 24-bit palettes, but they only use the top 4-bit, which are not colour-correct shrinking, since for example $e1 will be $e, but in reality it should be $d ($e1 is much closer to $dd than $ee).
So, with the "f4b" switch the converter will colour-correctly shrink all the colours, then extend them again (also colour-correctly). By this the non-AGA machines will show the colours without brightness shifting.
However, since the quantizer works on 24 bit and the shrinking happens after the palette quantization, it can produce collosions, which can be more worse, than a non-correctly bright picture. (E.g. both the colours "3f89b1" and "4590a9" will be "4488aa" and the final image will use less colours.) So, use with care.

2 steps quantization - 24 bit to 12 bit (and error distribution) then 12 bit to CLUT size.

[Leffmann]

Thanks, the ability to preserve color registers is particularly useful. Any chance for Mac OS X and Windows binaries? I could help you build them if you're not too protective of the sources.

[TCH]

Originally Posted by pandy71

2 steps quantization - 24 bit to 12 bit (and error distribution) then 12 bit to CLUT size.

That's what it's doing. Or what do you mean?

Originally Posted by Leffmann

Thanks, the ability to preserve color registers is particularly useful. Any chance for Mac OS X and Windows binaries? I could help you build them if you're not too protective of the sources.

There will be a Mac OS X version of course, for both PPC and intel Mac. (Check the download table.) I will get an OS X PPC installer very soon, then i will install FreeBSD PPC and Mac OS X PPC on my MDD and then i'll build binaries for them. For intel Mac, when i will get one, there will be support for it.

The source is closed, sorry.

Edit: If you have tips, how to breathe life into an intel OS X under Virtual Box or VMware, then maybe i don't need a real intel Mac.

[wXR]

Why keep the source closed?

[pandy71]

Originally Posted by jsr

That's what it's doing. Or what do you mean?

Accordingly to you some colors can be lost as first CLUT is calculated and later you doing 24 bit to 12 bit (upper nibble is copied to lower part exactly as in Amiga).
My point was that first 24 bit need to reduced to 12 bit with same approach as in AGA/ECS then next steps (or one step quantization but with 12 bit values as output).

Side to this any chance to describe EHB approach (how CLUT is created)?

[Mrs Beanbag]

ooh nice

[TCH]

Originally Posted by wXR

Why keep the source closed?

Why not?

Originally Posted by pandy71

My point was that first 24 bit need to reduced to 12 bit with same approach as in AGA/ECS then next steps (or one step quantization but with 12 bit values as output).

I may misunderstood, but do you suggesting that i should reduce the bitdepth to 12-bit before quantization?

Originally Posted by pandy71

Side to this any chance to describe EHB approach (how CLUT is created)?

Straight approach. I quantize the palette to 5-bit (2-32 colours), then i create the imaginary second palette over the index of 32 and then i just use the extended table in the eucledian colour search with the imaginary colors too.

Originally Posted by Mrs Beanbag

ooh nice

Thank you.

[Mrs Beanbag]

Originally Posted by jsr

Why not?

Well i suppose many of us could benefit from it. Personally i'd like to be able to incorprate a PNG loader into some of my own code, albeit nothing so sophisticated as yours.

I quantize the palette to 5-bit (2-32 colours), then i create the imaginary second palette over the index of 32 and then i just use the extended table in the eucledian colour search with the imaginary colors too.Thank you.

I have wondered before about the best way of doing this, but then i don't really know how colour quantization works anyway. Maybe there is another cunning trick one could use... thinking cap time!

[TCH]

Originally Posted by Mrs Beanbag

Personally i'd like to be able to incorprate a PNG loader into some of my own code, albeit nothing so sophisticated as yours.

There is libPNG, it's open source, you can use it both trough library calls, or just incorporating the code.

Originally Posted by Mrs Beanbag

I have wondered before about the best way of doing this, but then i don't really know how colour quantization works anyway. Maybe there is another cunning trick one could use... thinking cap time!

I didn't invent the wheel. My quantization code is heavily based on Xiaolin Wu's at here: http://www.ece.mcmaster.ca/~xwu/cq.c
I had to rewrite the whole code, to be able to use the algorithm as a function and also i thrown out the color replacing, because the euclidean color searching was more efficient, and i have added the ability to quantize to EHB or 12-bit and also to get the resulting image as a stream of lookup indexes; but the palette quantizer's algorithm - which is responsible for finding the best colours - is remained the same.

[wXR]

Originally Posted by jsr

Why not?

Well, there are a lot of reasons. If you have no plan to try and make money from the library, why not put the sources out there too, so others can carry on your work when you get bored with it? Releasing source (and properly licensing) early also means you can possibly engage other contributors.

It's your prerogative, but I don't see any advantage of a project like this being closed source.

[TCH]

Originally Posted by wXR

If you have no plan to try and make money from the library

It's not about the money.

Originally Posted by wXR

I don't see any advantage of a project like this being closed source.

Because you're viewing it from a different viewpoint.

[Cylon]

Maybe i missed that one:
Is the alpha channel preserved? If yes, how?

(p.s.: i donot read it all because it is not in coders section!)

[pandy71]

Originally Posted by jsr

Why not?I may misunderstood, but do you suggesting that i should reduce the bitdepth to 12-bit before quantization?

Well, from my perspective it seem to be obvious that as AGA and OCS/ECS use different bitdepth then different approach to create CLUT is necessary.
Going for 12 bit allow avoid losing some CLUT entries.

Originally Posted by jsr

Straight approach. I quantize the palette to 5-bit (2-32 colours), then i create the imaginary second palette over the index of 32 and then i just use the extended table in the eucledian colour search with the imaginary colors too.

I see - this will be question - not sure if this approach is correct - perhaps it should be like - reduce pixel level by half, count optimal 32 CLUT (half bright)?

Side to this i hope You are aware of this new class of algorithms:
http://members.ozemail.com.au/~dekker/NEUQUANT.HTML
http://www.cs.berkeley.edu/~dcoetzee/downloads/scolorq/
Probably they are to slow for native Amiga but for modern CPU they provide splendid results.
And Thank You Very Much!

[TCH]

Originally Posted by Cylon

Is the alpha channel preserved? If yes, how?

If by preserving you mean it is stored into the ILBM as it was, then the answer is of course no, since the ILBM does not support alpha. However, the alpha channel is not ignored; the program renders a 24-bit image from every type of PNG, including alpha channeled ones - the alpha channel defines the mixing ratio of the foreground and background colours. Try it with an alpha channeled PNG. If the PNG does not have a background colour, then the program defines it as black, but you can overwrite the background color, with the "fb" switch.

Originally Posted by pandy71

Well, from my perspective it seem to be obvious that as AGA and OCS/ECS use different bitdepth then different approach to create CLUT is necessary.
Going for 12 bit allow avoid losing some CLUT entries.

Unfortunately this is not true in this case, because the quantizer works on full 24-bit, so even if i convert the image to have only "symmetric" channel values ($ee, $55, $11, $99, etc.), the palette quantizer will generate colours which are not symmetric and we're at where we begun.

Originally Posted by pandy71

I see - this will be question - not sure if this approach is correct - perhaps it should be like - reduce pixel level by half, count optimal 32 CLUT (half bright)?

Yes, the correct method would be choosing only bright colours, because the dark ones will be generated (your reverse way works too, choose the secondary dark colours, then generate the primary bright palette) - however intensify or reduce the image's brightness can cause information loss, because of over or undersaturation. There could be some method to prevent this, but i am not a mathematician, the algorithm of the quantizer is done by Mr. Wu twenty years before, i just know what it does, but do not know why it works.

Originally Posted by pandy71

Side to this i hope You are aware of this new class of algorithms:
http://members.ozemail.com.au/~dekker/NEUQUANT.HTML
http://www.cs.berkeley.edu/~dcoetzee/downloads/scolorq/
Probably they are to slow for native Amiga but for modern CPU they provide splendid results.

I am aware of them; i tried them before and they gave much worse results, than Mr. Wu's quantizer.

Originally Posted by pandy71

And Thank You Very Much!

You are welcome.

[Mrs Beanbag]

my latest thinking is, one would want greater accuracy for the bright colours than the dark ones. So maybe one could start by only analysing the colours that have at least one component of 128 or greater. Then maybe you could pull off the least-useful bright colours one at a time and replace them with darker colours.

[Thorham]

Originally Posted by Mrs Beanbag

Personally i'd like to be able to incorprate a PNG loader into some of my own code, albeit nothing so sophisticated as yours.

Ask meynaf, he wrote one for his viewer.

[Cylon]

Originally Posted by jsr

If by preserving you mean it is stored into the ILBM as it was, then the answer is of course no, since the ILBM does not support alpha.

But as you know ILBM is just one of many possible chunks in an IFF file. You could (trying to get really creative here) just create a new chunk with the alpha channel!! And save it into the very same file! Nobody gets harmed, everybody ignores what is unknown....

What was the question again?

[Mrs Beanbag]

presumably "alpha" can just be regarded as another component in the palette entries, i assume ILBM packs the 12 bit palette entries into 16 bit words so one could use the upper 4 bits for alpha anyway

[wXR]

Originally Posted by jsr

Because you're viewing it from a different viewpoint.

What is yours, if I may?