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

[TCH]

Originally Posted by 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.

The problem is, if you reduce the brightness level, then it may result in colours which are undistinguishable for the human eye. If we increase the brightness, we may end in a lot of white-ish colour. But if we draw a line, that over this level we don't intensify, or under this level don't reduce, then the pixels gonna have different alterations, which will end in entirely different characteristics. (Besides a value of 128 is not bright. It's moderately dark.)

I think, instead of directly manipulating the channel values: a gamma increase or reduction should be done, then it can be quantized, then on the original (non-gamma corrected) image a color replacement can be performed, with the extended palette.

Originally Posted by Cylon

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....

If everybody will ignore it, then what purpose it will serve, aside from drastically increasing the size of the output image?
On the other hand, on Amiga, there is no alpha channel, even the graphic cards supports only 24-bit bitmaps.

Originally Posted by 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

Nope. ILBM always store the RGB components on 24-bit, but the OCS/ECS machines ignores the lower nibble of the channels.

Originally Posted by wXR

What is yours, if I may?

Sorry, but no, because you won't believe me and i don't want to engage in an unnecessary and pointless flamewar.

[Thorham]

Any plans for HAM support? It's not hard to do.

Originally Posted by jsr

On the other hand, on Amiga, there is no alpha channel, even the graphic cards supports only 24-bit bitmaps.

You don't need hardware alpha channel support to make use of an alpha channel.

[TCH]

Originally Posted by Thorham

Any plans for HAM support? It's not hard to do.

Maybe, but not now.

Originally Posted by Thorham

You don't need hardware alpha channel support to make use of an alpha channel.

I know, my converter supports alpha channel during rendering.

This is a full 64-bit RGBA PNG, with 16 bit for each channel:



And here are some conversions with different background colours:

png2ilbm pnggrad16rgba.png pnggrad16rgba_cyanbg.iff -fb=00ffff -d -hr -il

(http://oscomp.hu/depot/pnggrad16rgba_cyanbg.iff

png2ilbm pnggrad16rgba.png pnggrad16rgba_magentabg.iff -fb=ff00ff -d -hr -il

(http://oscomp.hu/depot/pnggrad16rgba_magentabg.iff

png2ilbm pnggrad16rgba.png pnggrad16rgba_yellowbg.iff -fb=ffff00 -d -hr -il

(http://oscomp.hu/depot/pnggrad16rgba_yellowbg.iff

By this way, alpha channel is supported: during rendering.
However, on the Amiga, nothing supports alpha channel, nor from hardware, neither from software. Besides, even if i would made a custom IFF chunk, which would contain the alpha data, i cannot expect existing software supporting it.

Simply there is no any point storing the alpha data.

[pandy71]

Originally Posted by jsr

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.

Ok then seem that Wu algorithm average color - indeed, http://www.ece.mcmaster.ca/~xwu/cq.c

This algorithm often produces optimized images with less quality degradation than other quantizers due to its methodology of optimizing based on clusters of colors that are closely related to one another rather than simply finding the most used colors in an image.

.

Side to this questions:

are You using inverse gamma before processing (i mean normal pictures have no linear RGB space and to be correctly processed then need to be set back in linear space by applying inverse gamma)? http://www.4p8.com/eric.brasseur/gamma.html (and as real inverse gamma is CPU intensive then i use in ffmpeg trick with negate/inverting levels before any processing and reapplying negate at the end to restore correct values)

did You considered non RGB color space (for example YCgCo which seem to be very fast to compute (add + shift) and provide very good color decorrelation http://en.wikipedia.org/wiki/YCgCo ) - i sometimes notice that this approach produce better CLUT.

Originally Posted by jsr

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.I am aware of them; i tried them before and they gave much worse results, than Mr. Wu's quantizer.You are welcome.

Ok, my point with half level was that in EHB only bright colors can be selected and HB colors are always half of the bright one - it may happen that HB colors will be same i.e. non optimal CLUT values halved will be equal thus focusing on selecting lower half should provide better CLUT usage IMHO.

I tried many times those new algorithms and from my perspective they are superior to everything (gimp/xnview with xiquantizer http://www.ximagic.com/q_results.html ) - especially for low CLUT (16 colors and less) spatial color seem to be hard to beat.

Originally Posted by jsr

However, on the Amiga, nothing supports alpha channel, nor from hardware, neither from software. Besides, even if i would made a custom IFF chunk, which would contain the alpha data, i cannot expect existing software supporting it.

Simply there is no any point storing the alpha data.

Ok, alpha 1 bit is supported by hardware ECS and maybe AGA(?) - You can set transparency for genlock http://amiga-dev.wikidot.com/hardware:colorx .

[Thorham]

Originally Posted by jsr

However, on the Amiga, nothing supports alpha channel, nor from hardware, neither from software. Besides, even if i would made a custom IFF chunk, which would contain the alpha data, i cannot expect existing software supporting it.

Simply there is no any point storing the alpha data.

It's true that there's absolutely no point in storing alpha channel in an IFF file, however, it may be useful to add some BMP out features. You could add an option to output the PNG as two BMP files: One 24bit for the RGB data, and one 8bit for the alpha data.

It's probably mostly useful for programmers, and if that PNG library you were talking about earlier is easy to use and capable enough, then such features are probably not worth the effort.

[TCH]

Originally Posted by pandy71

are You using inverse gamma before processing

Nope. My aim was to convert "normal" pictures, not tricky ones, which screws up conversion algorithms or deceive the human eyes.

Originally Posted by pandy71

did You considered non RGB color space

I did before, but the Wu quantizer only supports RGB colourspace, so it would be pointless. Maybe another quantizer could do the trick in YCgCo, but all of the other quantizers produced much worse results. (With the exception of IrfanView, but Irfan is not a helpful person, he did not told me, what algorithm he uses.)

Originally Posted by pandy71

Ok, my point with half level was that in EHB only bright colors can be selected and HB colors are always half of the bright one - it may happen that HB colors will be same i.e. non optimal CLUT values halved will be equal thus focusing on selecting lower half should provide better CLUT usage IMHO.

That's what i said too. I just said, that changing the brightness could cause colours to go white or black and the quantizer would select bad colours, so a gamma intensify would be better.

Originally Posted by pandy71

spatial color seem to be hard to beat

Public spatial quantizer algorithms produced much worse results, than the Wu quantizer. Maybe something is missing from the picture.

Originally Posted by pandy71

Ok, alpha 1 bit is supported by hardware ECS and maybe AGA(?) - You can set transparency for genlock http://amiga-dev.wikidot.com/hardware:colorx .

This is applying for colour registers, not for pixels, thus it's impossible to convert most alpha layered PNG image to use this technique, with the only exception are the ones which contains palette assigned alpha values and uses only 32 colours, those could be converted by using their topmost bit, but the ILBM have a "pure" 24-bit RGB palette and not supports this.

Originally Posted by Thorham

It's true that there's absolutely no point in storing alpha channel in an IFF file, however, it may be useful to add some BMP out features. You could add an option to output the PNG as two BMP files: One 24bit for the RGB data, and one 8bit for the alpha data.

And what good it would do for us on the Amiga?

Originally Posted by Thorham

It's probably mostly useful for programmers, and if that PNG library you were talking about earlier is easy to use and capable enough, then such features are probably not worth the effort.

LibPNG is the industry standard, it supports everything in PNG. Also it's part of most of systems, so you can use it through library calls, or - since it's opensource and (thankfully) it's not GPL - you can just copy the sources from it and integrate into your program. Suits most needs of most projects.
I only did not used it, because i found it not enough lightweight for a classic Amiga; so i just wrote my own PNG handler, it also can load and render any PNG, but it only weighs 24 kB (as in compiled AMD64 binary).

[pandy71]

Originally Posted by jsr

Nope. My aim was to convert "normal" pictures, not tricky ones, which screws up conversion algorithms or deceive the human eyes.

"Normal" pictures have nonlinear RGB space (as such any operations on non linear space will give unavoidable errors)

Originally Posted by jsr

That's what i said too. I just said, that changing the brightness could cause colours to go white or black and the quantizer would select bad colours, so a gamma intensify would be better.

Ok, perhaps same as in HAM case some hybrid - tricky approach is required.

Originally Posted by jsr

Public spatial quantizer algorithms produced much worse results, than the Wu quantizer. Maybe something is missing from the picture.

Ok, i have different impression but ok.

Once again Thanks for a new software.

[TCH]

Originally Posted by pandy71

"Normal" pictures have nonlinear RGB space (as such any operations on non linear space will give unavoidable errors)

Perhaps. But until this point, i had no problem with normal pictures. Whenever problems will occur, i will rethink my approach.

Originally Posted by pandy71

Ok, perhaps same as in HAM case some hybrid - tricky approach is required.

Currently, i trying with pre intensify/reduce the gamma correction/brightness of the picture before EHB quantizing. Strangely i got the best results with 1.1 gamma, all other methods said thursday. With pre-intensified gamma at ~1.1 i got a slight smoother picture, but nothing earthshaking.

Originally Posted by pandy71

Ok, i have different impression but ok.

Maybe you got a different source than me.

Originally Posted by pandy71

Once again Thanks for a new software.

You are welcome.

Edit: Nope, on small resolution the 1.1 gamma produced much worse picture. So, not brightness, nor gamma are good for pre-transform before EHB quantization.

[Cylon]

Originally Posted by jsr

....If everybody will ignore it, then what purpose it will serve, aside from drastically increasing the size of the output image?
On the other hand, on Amiga, there is no alpha channel, even the graphic cards supports only 24-bit bitmaps...

Everybody (every tool) unfamilar with this chunk will ignore it(!). Note the difference. Think about the future. You want to have a future for your tool, aint you?
Well, your tool can have an option to include/exclude that alpha?? Maybe a 1bit-alpha (mask!)?
Why not create an entire new image class, likewise iff24?

Why should a user care about image's filesize anyway? This is not 1995 anymore!
Make it an option. Design it wisely. Publish the specifications.
The DataType will follow.
(This is how it would work on Amiga).
Btw. gfx cards supports any 24 bit image, which could also be a composition of many different sources of images, therefore also a combined color+alpha image. it is not the hardware that defines the src image.

[Cylon]

Originally Posted by Thorham

It's true that there's absolutely no point in storing alpha channel in an IFF file, however, it may be useful to add some BMP out features. You could add an option to output the PNG as two BMP files: One 24bit for the RGB data, and one 8bit for the alpha data.

Yeah, that makes perfect sense: Not storing the aplha channel in an IFF chunk while PNG uses the very same chunk mechanism but instead creating an additional file in a non-common format with probably bigger file size.

[TCH]

Originally Posted by Cylon

Everybody (every tool) unfamilar with this chunk will ignore it(!). Note the difference.

I know what's the difference, but since currently every tool would be unfamiliar with this chunk, every tool will ignore it.

Originally Posted by Cylon

Think about the future. You want to have a future for your tool, aint you?

Future? We're talking about a 30 year old retrocomputer and fileformat. I want to support what exists, not dream about what is not and never will.

Originally Posted by Cylon

Well, your tool can have an option to include/exclude that alpha??

It would be pointless.

Originally Posted by Cylon

Maybe a 1bit-alpha (mask!)?

The genlock's 1-bit transparency is applied for palette entries (maximum 32 on top of that). That cannot be applied to pixels.

Originally Posted by Cylon

Why not create an entire new image class, likewise iff24?

Not my competence. Whenever something will appear what can do something with alpha layers in the ILBM i will support it. I won't create unnecessary and/or useless features, just to create them.

Originally Posted by Cylon

Why should a user care about image's filesize anyway?

Because size does matter.

Originally Posted by Cylon

This is not 1995 anymore!

On the classic Amiga, it is. Not too much memory or HDD, i won't waste it for unneeded and unusable data.

Originally Posted by Cylon

Make it an option. Design it wisely. Publish the specifications.

What do you expecting? Somebody will port Photoshop or GIMP to the Amiga? There won't be any programs what will support it.

Originally Posted by Cylon

Btw. gfx cards supports any 24 bit image, which could also be a composition of many different sources of images, therefore also a combined color+alpha image. it is not the hardware that defines the src image.

What?

[pandy71]

Originally Posted by jsr

The genlock's 1-bit transparency is applied for palette entries (maximum 32 on top of that). That cannot be applied to pixels.

nope, can be applied - on ECS (AGA?) bitplane can be used as ZD (genlock) plane. So 1 bit alpha can be on plane not only on CLUT entries.

[Thorham]

Originally Posted by Cylon

Yeah, that makes perfect sense: Not storing the aplha channel in an IFF chunk while PNG uses the very same chunk mechanism but instead creating an additional file in a non-common format with probably bigger file size.

It makes a lot more sense then storing the alpha channel in an IFF chunk that not a single program can (and likely never will) use. Furthermore, I suggested it as an option, so that the alpha channel can obtained as an 8bit gray scale BMP (easy file format, easy to use), and is not simply lost (and also the original 24bit color data).

BMP is of course very common in that it can be read by just about every image processing software in existence. This includes 8bit per pixel palette and gray scale images. BMP is anything but uncommon.

So, yes, it makes perfect sense. Whether or not jsr wants to implement it or not, is up to jsr.

[TCH]

Originally Posted by pandy71

nope, can be applied - on ECS (AGA?) bitplane can be used as ZD (genlock) plane. So 1 bit alpha can be on plane not only on CLUT entries.

I started out from the description, what you showed me, but let's just say, this is true. It would be still impossible to store the alpha, because such thing like '1-bit alpha' is not exists! In this entire thread, everybody confuses transparency with translucency and the alpha layer is the latter one. On 1-bit, you can only store transparency (0 = transparent, 1 = opaque); to have a real alpha layer, you'll need at least two bits, then at least, you'll have two translucent state.
Do you have an idea how this image

would look like with an '1-bit alpha'? Like this!

(Replace the black with anything you want, but you get the idea.)

Originally Posted by Thorham

It makes a lot more sense then storing the alpha channel in an IFF chunk that not a single program can (and likely never will) use. Furthermore, I suggested it as an option, so that the alpha channel can obtained as an 8bit gray scale BMP (easy file format, easy to use), and is not simply lost (and also the original 24bit color data).

BMP is of course very common in that it can be read by just about every image processing software in existence. This includes 8bit per pixel palette and gray scale images. BMP is anything but uncommon.

So, yes, it makes perfect sense. Whether or not jsr wants to implement it or not, is up to jsr.

Actually, both ideas are makes no sense. It does not matter, that i store the alpha layer in a custom - thus generally unusable - chunk, or in a separate file, in an alien format to the Amiga top on that: BMP is anything but common (and usable!) on the Amiga. I know, that some programs can import BMP files, but in general a BMP file is useless on the Amiga - even if palette based BMP-s can be shown after a C2P conversion - it makes no sense to store Amiga pictures in BMP, and absolutely makes no sense to store data uniterpretable for the Amiga - in a format which is alien to the Amiga.

[pandy71]

Originally Posted by jsr

I started out from the description, what you showed me, but let's just say, this is true. It would be still impossible to store the alpha, because such thing like '1-bit alpha' is not exists! In this entire thread, everybody confuses transparency with translucency and the alpha layer is the latter one. On 1-bit, you can only store transparency (0 = transparent, 1 = opaque); to have a real alpha layer, you'll need at least two bits, then at least, you'll have two translucent state.
Do you have an idea how this image
would look like with an '1-bit alpha'? Like this!

Well, don't forget about dither (hires and shires can make this quite well).
I'm not pushing for Alpha - just saying how things looks from HW perspective.

btw
just made short comparison for Wu and Spatial Color Quantization.

Original 24 bit


Wu


Spatial Color Quantization (15 colors LUT)

[Thorham]

Originally Posted by jsr

it makes no sense to store Amiga pictures in BMP, and absolutely makes no sense to store data uniterpretable for the Amiga - in a format which is alien to the Amiga.

I never said that that would be a good idea I suggested BMP output as option so that the images can be used in 24bit graphics programs that don't support PNG (Adpro ).

[TCH]

Originally Posted by pandy71

Well, don't forget about dither (hires and shires can make this quite well).

Dither and higher resolution cannot solve a big "hole" (or a bunch of small holes) on the screen.

Originally Posted by pandy71

btw
just made short comparison for Wu and Spatial Color Quantization.

And what do you think of the results? Just because i think the spatial one may have stronger and sharper colours (actually too sharp and strong i think, it's garish), but it is extremely noisy compared to the Wu. I believe you use a high resolution flat monitor, so you don't see it from near; on my 1024x768 CRT it's very noisy.

Originally Posted by Thorham

I never said that that would be a good idea I suggested BMP output as option so that the images can be used in 24bit graphics programs that don't support PNG (Adpro ).

But why should i put a BMP output into an ILBM converter? If you want to convert PNG to BMP, there's already tons of tools for that.

Thread:
1.0.1 released, with some minor bugfixes.

[Thorham]

Originally Posted by jsr

But why should i put a BMP output into an ILBM converter?

Because of the alpha channel thing. Anyway, it was just a suggestion. If you don't like it, don't add it. It's not a big deal

[TCH]

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.

[pandy71]

Originally Posted by jsr

Dither and higher resolution cannot solve a big "hole" (or a bunch of small holes) on the screen.

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).

Originally Posted by jsr

And what do you think of the results? Just because i think the spatial one may have stronger and sharper colours (actually too sharp and strong i think, it's garish), but it is extremely noisy compared to the Wu. I believe you use a high resolution flat monitor, so you don't see it from near; on my 1024x768 CRT it's very noisy.

Once again dither (and noise shaping) are very important - to verify result (perceived) Amiga (real one) connected to bandlimited display (such as 1084) probably will be significantly better - in real life (especially in CRT) such signal will be averaged and will produce better quality - don't ignore limited bandwidth available at analog Amiga output (VIDIOT or Video DAC is very crude in Amiga - few resistors and transistor).

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).
And my comment about displays - modern LCD have significantly higher Kell factor and as such they NOT blurring video as CRT's (of course you can always resize video 2 or 4 times with point resampling and introduce some Gaussian blur to simulate CRT) they usually provide worse results than CRT's and TV in such extreme cases (low CLUT size).