English Amiga Board


Go Back   English Amiga Board > Main > Amiga scene

 
 
Thread Tools
Old 17 April 2015, 08:48   #1
TCH
Newbie Amiga programmer

 
Join Date: Jun 2012
Location: Front of my A500+
Age: 31
Posts: 108
new PNG to ILBM converter for Amiga, MorphOS, Linux, FreeBSD, Haiku and Solaris

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:
Code:
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:

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

Code:
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.
TCH is offline  
AdSense AdSense  
Old 17 April 2015, 14:20   #2
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by jsr View Post
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.
pandy71 is offline  
Old 17 April 2015, 17:10   #3
Leffmann

 
Join Date: Jul 2008
Location: Sweden
Posts: 2,029
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.
Leffmann is offline  
Old 17 April 2015, 17:41   #4
TCH
Newbie Amiga programmer

 
Join Date: Jun 2012
Location: Front of my A500+
Age: 31
Posts: 108
Quote:
Originally Posted by pandy71 View Post
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?
Quote:
Originally Posted by Leffmann View Post
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.

Last edited by TCH; 17 April 2015 at 17:43. Reason: Added intel OSX emulation part
TCH is offline  
Old 18 April 2015, 08:56   #5
wXR
Registered User
 
Join Date: Mar 2009
Location: New York
Posts: 552
Why keep the source closed?
wXR is offline  
Old 18 April 2015, 12:36   #6
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by jsr View Post
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)?
pandy71 is offline  
Old 18 April 2015, 13:30   #7
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
ooh nice
Mrs Beanbag is offline  
Old 18 April 2015, 21:05   #8
TCH
Newbie Amiga programmer

 
Join Date: Jun 2012
Location: Front of my A500+
Age: 31
Posts: 108
Quote:
Originally Posted by wXR View Post
Why keep the source closed?
Why not?
Quote:
Originally Posted by pandy71 View Post
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?
Quote:
Originally Posted by pandy71 View Post
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.
Quote:
Originally Posted by Mrs Beanbag View Post
ooh nice
Thank you.

Last edited by TCH; 18 April 2015 at 21:06. Reason: missing 'do' keyword
TCH is offline  
Old 18 April 2015, 21:10   #9
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
Quote:
Originally Posted by jsr View Post
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.

Quote:
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!
Mrs Beanbag is offline  
Old 18 April 2015, 23:04   #10
TCH
Newbie Amiga programmer

 
Join Date: Jun 2012
Location: Front of my A500+
Age: 31
Posts: 108
Quote:
Originally Posted by Mrs Beanbag View Post
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.
Quote:
Originally Posted by Mrs Beanbag View Post
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.

Last edited by TCH; 18 April 2015 at 23:07. Reason: comma => semicolon
TCH is offline  
Old 19 April 2015, 13:47   #11
wXR
Registered User
 
Join Date: Mar 2009
Location: New York
Posts: 552
Quote:
Originally Posted by jsr View Post
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.
wXR is offline  
Old 19 April 2015, 17:20   #12
TCH
Newbie Amiga programmer

 
Join Date: Jun 2012
Location: Front of my A500+
Age: 31
Posts: 108
Quote:
Originally Posted by wXR View Post
If you have no plan to try and make money from the library
It's not about the money.
Quote:
Originally Posted by wXR View Post
I don't see any advantage of a project like this being closed source.
Because you're viewing it from a different viewpoint.
TCH is offline  
Old 19 April 2015, 22:42   #13
Cylon
Registered User

 
Join Date: Oct 2014
Location: Europe
Posts: 466
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!)
Cylon is offline  
Old 19 April 2015, 23:03   #14
pandy71
Registered User
 
Join Date: Jun 2010
Location: PL
Posts: 1,546
Quote:
Originally Posted by jsr View Post
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.

Quote:
Originally Posted by jsr View Post
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!
pandy71 is offline  
Old 20 April 2015, 00:57   #15
TCH
Newbie Amiga programmer

 
Join Date: Jun 2012
Location: Front of my A500+
Age: 31
Posts: 108
Quote:
Originally Posted by Cylon View Post
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.
Quote:
Originally Posted by pandy71 View Post
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.
Quote:
Originally Posted by pandy71 View Post
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.
Quote:
Originally Posted by pandy71 View Post
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.
Quote:
Originally Posted by pandy71 View Post
And Thank You Very Much!
You are welcome.
TCH is offline  
Old 20 April 2015, 01:11   #16
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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.
Mrs Beanbag is offline  
Old 20 April 2015, 01:34   #17
Thorham
Computer Nerd

Thorham's Avatar
 
Join Date: Sep 2007
Location: Rotterdam/Netherlands
Age: 41
Posts: 2,972
Quote:
Originally Posted by Mrs Beanbag View Post
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.
Thorham is offline  
Old 20 April 2015, 01:48   #18
Cylon
Registered User

 
Join Date: Oct 2014
Location: Europe
Posts: 466
Quote:
Originally Posted by jsr View Post
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?
Cylon is offline  
Old 20 April 2015, 01:51   #19
Mrs Beanbag
Glastonbridge Software
Mrs Beanbag's Avatar
 
Join Date: Jan 2012
Location: Edinburgh/Scotland
Posts: 2,202
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
Mrs Beanbag is offline  
Old 20 April 2015, 02:29   #20
wXR
Registered User
 
Join Date: Mar 2009
Location: New York
Posts: 552
Quote:
Originally Posted by jsr View Post
Because you're viewing it from a different viewpoint.
What is yours, if I may?
wXR is offline  
AdSense AdSense  
 


Currently Active Users Viewing This Thread: 1 (0 members and 1 guests)
 
Thread Tools

Similar Threads
Thread Thread Starter Forum Replies Last Post
new WAV to 8SVX converter for Amiga, MorphOS and Linux TCH Amiga scene 21 08 June 2017 05:37
FS-UAE 2.0 for Windows, Mac OS X, Linux and FreeBSD FrodeSolheim News 6 01 November 2012 00:25
PNG Icon to Color Icon Converter? Leandro Jardim request.Apps 1 24 May 2010 05:39
UAE for Sun Solaris (Sparc) commie1974 support.OtherUAE 8 31 August 2006 22:46
convert .info to png or jpg(with linux) lostfriend request.Apps 4 22 March 2006 02:26

Posting Rules
You may not post new threads
You may not post replies
You may not post attachments
You may not edit your posts

BB code is On
Smilies are On
[IMG] code is On
HTML code is Off

Forum Jump


All times are GMT +2. The time now is 05:00.


Powered by vBulletin® Version 3.8.8 Beta 1
Copyright ©2000 - 2017, vBulletin Solutions, Inc.
Page generated in 0.45076 seconds with 11 queries