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

[Thorham]

Originally Posted by jsr

It's not about if i like it or not, but it is unnecessarily. If you want to grab the alpha channel from a PNG and save it to BMP, then it's two click in IrfanView.

You could also just use Xnview to save images as IFF

[TCH]

Originally Posted by pandy71

It can as averaging (related to limited bandwidth) can't be ignored - this is main principle of dithering and noise shaping - thanks to this we have single bit high-end (32 bit) audio converters.
single bit ZD can be translated in genlock electronic to intermediate steps (analog) transparency even with hardswitching genlocks (as they have limited bandwidth/slew rate of switching) and even if they have bandwidth more than 7MHz still there is plenty of other bandlimiting filters (and there is temporal dithering available as option).

And how can ILBM store this? How will this work on my A500+

Originally Posted by pandy71

Personally i don't care about noise when it provide better psychovisual effect. I was just curious about how Wu will perform against color spatial (as Your observations was contradictory to mine).
SCQ perform obviously better than Wu (15 colors provide picture closer to original) and with typical bandwidth for SCART input in regular TV (around 5 - 6MHz maximum) should provide better visual results thanks to averaging.
Algorithms like Wu provide good results with relatively high number of colors in CLUT (probably somewhere around 64 - 128 colors at least).

I'll put spatial quantization into PNG2ILBM as an option and i'll see in life, which produces better results on my 1084, with EHB. If you're right, then the overdiffused image of spatial quantization will look better on an old PAL monitor (which is my aim after all).

Originally Posted by Thorham

You could also just use Xnview to save images as IFF

I tried to save IFF-s with XnView, but it only can save to IFF as 256-coloured grayscale. I've searched in google, in manual, tried to set the software, but no luck.

Beside, try to use use XnView on BSD or real Amiga. It only supports Linux and Mac OS X (and only the x86 versions on top of that).

[Thorham]

Originally Posted by jsr

I tried to save IFF-s with XnView, but it only can save to IFF as 256-coloured grayscale. I've searched in google, in manual, tried to set the software, but no luck.

Strange. Are you using a recent version? It should just work.

Originally Posted by jsr

Beside, try to use use XnView on BSD or real Amiga. It only supports Linux and Mac OS X (and only the x86 versions on top of that).

Yeah, sucks. For Amiga it would be nice if image processors like Adpro supported PNG. Some do, but the codecs are old.

[TCH]

Originally Posted by Thorham

Strange. Are you using a recent version? It should just work.

Latest.

Edit: Mystery solved. I tried the windows version of XnView in WINE and it can save a coloured ILBM. The Linux version cannot. Ultimate shame on the XnView team...
Still, XnView can only quantize to 2^n colours, don't support EHB, nor register preservation and it cannot quantize to a fix palette...

Originally Posted by Thorham

Yeah, sucks. For Amiga it would be nice if image processors like Adpro supported PNG. Some do, but the codecs are old.

I only know one program, which can import (palette-based) PNG-s, it's PPaint, but the results are awful. Also it cannot quantize to EHB. (Nor XnView can.)

[pandy71]

Originally Posted by jsr

And how can ILBM store this? How will this work on my A500+

Based on this http://www.shikadi.net/moddingwiki/LBM_Format there is few opportunities but my point was only related to HW capabilities - as a software creator you are free to ignore any my comments.
And once again any new software for Amiga is more than appreciated.

Originally Posted by jsr

I'll put spatial quantization into PNG2ILBM as an option and i'll see in life, which produces better results on my 1084, with EHB. If you're right, then the overdiffused image of spatial quantization will look better on an old PAL monitor (which is my aim after all).

Same as earlier - purely up to You - from my experience SCQ produce superior results to any other known to me color quantization algorithm - it is slow, memory hog but for 16 colors hard to beat.
Once again Thank You.

[Cylon]

Originally Posted by jsr

I only know one program, which can import (palette-based) PNG-s, it's PPaint, but the results are awful. Also it cannot quantize to EHB. (Nor XnView can.)

I don't understand: a palette based picture is 8bit rgb, which is natively supported by PPaint on any 24 bit capable Amiga (AGA or RTG). How can the results being awful? Those pics should be pixel perfect. And i cannot remember any awful encounter during all the years.
And of course can PPaint recalc/remap palettes to EHB or simply a 64color palette. Please explain. PPaint also loads and remaps 24Bit PNGs without any problems.

It almost looks like you want to blame other people's software for the lack of hardware (gfx wise) on your side?

[TCH]

Originally Posted by pandy71

Based on this http://www.shikadi.net/moddingwiki/LBM_Format there is few opportunities but my point was only related to HW capabilities - as a software creator you are free to ignore any my comments.

You're referring to "Deep Images"? That's a native 24 or 32-bit picture, you cannot use that on a regular Amiga.

Originally Posted by pandy71

Same as earlier - purely up to You - from my experience SCQ produce superior results to any other known to me color quantization algorithm - it is slow, memory hog but for 16 colors hard to beat.

We'll see. Do you happen to have a spatial algorithm, which is in C and not C++? I would like to avoid rewriting it.

Originally Posted by pandy71

Once again Thank You.

You are welcome.

Originally Posted by Cylon

I don't understand: a palette based picture is 8bit rgb, which is natively supported by PPaint on any 24 bit capable Amiga (AGA or RTG).

And how does this relate to quantizing?

Originally Posted by Cylon

How can the results being awful?

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


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


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

Originally Posted by Cylon

And of course can PPaint recalc/remap palettes to EHB or simply a 64color palette.

Either i remembered wrong, or it was an older PPaint, which did not supported it. PPaint 7.1 did; see above.

Originally Posted by Cylon

PPaint also loads and remaps 24Bit PNGs without any problems.

And how about 48-bit ones? 64? How about quantizing to a fix palette, or preserve/override colour registers?

Originally Posted by Cylon

It almost looks like you want to blame other people's software for the lack of hardware (gfx wise) on your side?

Nope.

[pandy71]

Originally Posted by jsr

You're referring to "Deep Images"? That's a native 24 or 32-bit picture, you cannot use that on a regular Amiga.

Not likely, second BODY, CAMG Dual Playfield - i see some opportunities but once again - this is highly optional, probably never used by anyone from my perspective i would say don't bother - my comments was related purely to HW capabilities (and accordingly to my knowledge no existing software use this kind of features introduced in ECS but perhaps im wrong then it can be nice to see how it was solved).

Originally Posted by jsr

We'll see. Do you happen to have a spatial algorithm, which is in C and not C++? I would like to avoid rewriting it.

Nope, sorry.

[TCH]

Originally Posted by pandy71

Not likely, second BODY, CAMG Dual Playfield

A second BODY could be used for storing alpha, but still, nothing existsing stuff supports it. As for dual playfield, that's not good for this. 15 colour only and the foreplane's transparency is only shows the background, it's not that kind of transparency, which could be used for an alpha emulation.

Originally Posted by pandy71

my comments was related purely to HW capabilities (and accordingly to my knowledge no existing software use this kind of features introduced in ECS but perhaps im wrong then it can be nice to see how it was solved).

I have no idea.

Originally Posted by pandy71

Nope, sorry.

That's too bad. Because the spatial quantization sources are in C++, which puts a little object in my way. Namely, i have to learn C++ first, if i want to rewrite it. Since i'm already working on another stuff, it won't be done soon.

[IvanEBC]

3 years later .....

cant find png2ilbm to download ... blank pages where the link should be ... anyone got this handy to share?

thanks

[DamienD]

Found this, hopefully it's what you're after:

png2i031.lha     35k     png2ilbm-amiga-68020.lha

[IvanEBC]

Thanks Damien.....
Hmm, on the Amiga? Sorry, was thinking it was windows software, i can't imagine the time required to convert 4000 frames on an Amiga,,,

[DrBong]

@IvanEBC
Have a look at the thread title. No Windoze version listed, but there are Linux/FreeBSD/Solaris/Haiku versions for PC if they're of any use. The MorphOS version might have some grunt too if you have the necessary Amiga/PPC hardware or the required software set-up under emulation.

http://oscomp.hu/?games/s/PNG2ILBM

[IvanEBC]

Was after a windows version i'll just use one of those bootable linix distros.
I found and spoke to the guy who creates these Amiga vids and has passed on the software onto me.. thank you Fellas

[Gorf]

Originally Posted by TCH

HAM-support

Maybe, but not now.

here you go. that would be a reason to open the source and let others fill in the missing parts...

I see the advantages (mostly financial) of closed source in some areas, but clearly fail to see it here.

There are sooo many abandoned tools in Aminet, where you could learn some tricks, improve the program or port it to AROS or PPC... if only the source code was available.

[TCH]

@IvanEBC: In the meantime the server owner updated to php7 and pulled mysql from under my feet. Fixed, here you go: http://bgafc.t-hosting.hu/prgv.php?p=2
As for windows, there is no windows version and there will not be. I don't use or have windows at all.

@Gorf:
No, this is no reason. HAM6/HAM8 support is already done, i just need to pull mysfelf together and release v1.1.0.

[TCH]

Originally Posted by TCH

i just need to pull mysfelf together and release v1.1.0.

For which the time has come now.

PNG2ILBM v1.1.0 has been released with HAM and ACBM support:
- Numeric arguments are now accepting hexadecimal (prefix: 0x), octal (prefix: 0o) and binary (prefix: 0b) numbers too, not just decimal.
- Enhanced 12-bit quantization, no more color collosions. (But unused colors still can occur.)
- Quantization now detects if the palette has not been changed during quantization and performs a simple color match instead of euclidean search, which vastly speeds up quantization.
- Unified (one-step) colorcounting in quantization, which slightly speeds up quantization if the desired number of colors in the image is lower than or equal to the actual number of colors. (And negligibly slows it down if it is higher.)
- Colorcounting now also can "export" it's "trees" which can be used to significantly speed up euclidean search by assigning the results to a pixel value.
- Cardinally faster dithering.
- New option: "kp", keeps original palette. This is useful, if you used a modern painter to create a palette based image and you want to convert it to ILBM, with the palette entries simply copied, instead of quantized. Further information in the program's help.
- New option: "ham", creates HAM image. HAM5 and HAM7 are not supported, only HAM6 and HAM8.
- New option: "cs", shows how much unique colors the resulting image got.
- New option: "acbm", saves the output image in Amiga Continuous Bitmap (ACBM) instead of Interleaved Bitmap (ILBM).
- A bit more readable output.
- Some minor internal changes.
- Fixed: Missing source pointer incrementing in 4-bit PNG-s, causing shifts in picture or segfaults.
- Fixed: Register preserving and overriding did not worked, if the number of allowed colours exceeded the colour count.
- Fixed: Page width and height maximum checking was checked the image width and height instead.
- Fixed: Non-freed areas during color counting.
- Fixed: Image aspect ratios in the BMHD chunk were incorrect.
- Fixed: Missing padding byte in odd-length ILBM files.
- Fixed: Segfault if a numeric argument was left empty.
- New platforms: Solaris i386, Haiku AMD64, OpenBSD AMD64, NetBSD i386, NetBSD AMD64

Notes:
- As stated in the help, if you convert into a HAM6 image, the usage of option

f4b

(force 4-bit) is highly recommended, otherwise the image might be full of "stripes". (You can see what i mean here: HAM6 with 24-bit palette, HAM6 with 12-bit palette)
- It turned out, that under 68000 the program is much faster if it's only use the

mathffp.library

, instead of the

mathieee#?.library

-s, while under 68020, it's much slower (i don't know how did SASC manage to do that), so from now, the 68000 version needs only the

mathffp.library

which is in the KickStart already.
- Linux PowerPC and MorphOS PowerPC platform support has NOT been dropped, it's just, my flat is a mess now and i do not have the means, the space and the time to put my PowerPC environments together, so no new version for those two platforms, at least for now.

Downloads are here.

[TCH]

I've discovered a bug, which was introduced in v1.1.0: if the entire palette was overridden with

"sr"

or

"srl"

, then the resulting image was erroneous; this is now fixed. Download links are the same.

[TCH]

I've discovered yet another bug, but this one was in the program since v1.0.0: the program could not interpret upper case letters in the hexa color codes of

"sr"

and

"srl"

; this is now fixed. Download links are the same.

[TCH]

Zener reported that on a real Amiga the program crashes when he tries to convert an RGBA32 PNG. The cause was a SASC bug (?) which caused the program to crash right at the calling of the pixel renderer function. Neither the PNG_6_8 image renderer, nor the pixel renderer had any bugs, the crash was caused by the call itself, for reasons still unknown to me; none of the other PNG_T_D renderers did this, nor the other compilers on other platforms in that function. (The binary Bebbo's Amiga GCC had generated was working flawlessly too; only SASC did this.)

The "fix" was a very ugly hack: calling fprintf() (actually any function does it) right before the call. (Yes, WTF.) What is even more confusing, that executing the call is actually not necessary: if it is present in the code, but blocked, the code still works. (Yes, even bigger WTF.)
See for yourselves: http://oscomp.hu/depot/wtf_sasc.c

Fixed 1.1.3 versions are available at the download link above. (Only for Amiga, the other platforms were not affected.)

If anyone knows what is this and why it happens, feel free to enlighten me, because i hate being dumb.