New version of PNG library (now v3.2.q)

User contributed sources that have become inactive, deprecated, or generally unusable. But ... we don't really want to throw them away either.
Post Reply
yetifoot
Posts: 1710
Joined: Sep 11, 2005 7:08
Location: England
Contact:

New version of PNG library (now v3.2.q)

Post by yetifoot »

OK, I decided to make the new version fully official today, version 3.2.q (Hooray for weird version number changes!)

http://www.mediafire.com/download.php?avx5a8d5lec9kcb

For most users, you can just carry on using it as normal, but now, thanks to 1000101, there are some new goodies for advanced users:

The changes for this version are as follows:
1) Added memory save function to save to a memory image (png_save_mem creates and returns a memory pointer).
2) Added pixel format functions to return the color type and bit depth of a png.
3) Added "version 2" load, save functions which are more low-level and can be used by any graphics library
via the use of callbacks.
4) Updated conversion code to make conversion from any png to (almost) any image format possible. Total
output pixel formats include PALETTE_8, RGB_16, RGB_32, ARGB_32, ABGR_32. "Version 1" functions
only support ARGB_32 and ABGR_32.
5) Internal function tables are used to streamline the decode sequence resulting in a 20% speed increase.

---------------------------------------
OLD MESSAGE:

OK, I upped a new version:

http://www.mediafire.com/download.php?3v0lvg14ws7gq0g

If you are using v1.9.3 you should upgrade to this if you intend to use the static zlib version on windows (The build of that was broken in that version).
If you are using v1.9.2 you should upgrade if you use the dimensions functions (A bug in those was fixed in v1.9.3).
Anyone else might just want to upgrade to this version because I reworked some of the code and it's now about 40% faster in my tests.
Quote:

The changes for this version are as follows:
1) The prebuilt windows static zlib version was bugged in v1.9.3 due to a misbuild. That is now rectified.
2) Static versions of the library are now built under a new name, 'libfbpngs.a'. This will mean you can keep
both in your FreeBASIC lib/ directory without having any clashes as it takes precedence. Hopefully this
will help stop a lot of the problems people had using the static version.
3) A lot of code has been changed in png_image_convert.bas in order to improve it's efficiency. I am seeing
around 40% faster times on my machine.

---------------------------------------
OLD MESSAGE:

http://www.streetcds.co.uk/fbpng_v1_9_3.tar.gz

The changes for this version are as follows:
1) A bug was found, and fixed in the PNG dimensions code thanks to user dreamerman. This bug affected
users who called png_dimensions many times.
2) Some new logic has been added to set the default image type based on the FB version has been added
thanks to 1000101. It now detects if you are using <= 0.17, and will use the old image format,
otherwise it will use the new image format. This means that for most users who will be using 0.20 FBC
the default has changed. It won't effect many people though I hope, as most of those will be using
the new image format anyway, and it's only people who do more low level stuff with the buffer who will
be negatively affected. If you find your program misbehaves with the new version of FBPNG, then try
specifying PNG_TARGET_FBOLD in your png_load calls.

---------------------------------------
OLD MESSAGE:

http://www.streetcds.co.uk/fbpng_v1_9_2.tar.gz

fbpng has now been modified, so that it will work with the version of ImageDestroy that
that comes with FB 0.21. However, YOU SHOULD NOT USE IMAGEDESTROY. This addition is
partly a compatibility patch to help people out, you should be using png_destroy instead
in order to be as future-proof as possible. This change means that you cannot use ImageDestroy
anymore if you are using FB 0.20. You should either update your code to use png_destroy, or
just carry on using your old version of fbpng. Also, if you plan to use the STATICZ version
you should do;

Code: Select all

	#define PNG_STATICZ 1
	#include "fbpng.bi"

in your program, as otherwise it will still try to link to a dynamic version of zlib. Thank
you to Z!re for making me aware of this.

The major change for this version of fbpng, is that buffers created by fbpng will now be
aligned in memory to a multiple of 16 bytes, this is to match the change in the FB 0.21
ImageCreate/Destroy functions, which now also do the same, and allows users who know SSE to
be able to use it more effectively. Thanks to {1000101} for helping me out with the method
that this uses, and to counting_pine, whose patch I modified and incorperated.

---------------------------------------
OLD MESSAGE:

http://www.streetcds.co.uk/fbpng_v1_9_1.tar.gz

Changes:
You MUST now use the png_destroy() sub to free up the memory that gets allocated by png_load/png_load_mem

---------------------------------------
OLD MESSAGE:

Now another new version:

http://www.streetcds.co.uk/fbpng_v1_9_0.tar.gz

Changes:
Added the changes recommended in the thread:
added #inclib "fbpng" to the fbpng.bi
added default target
remade the BMPs so no more false positives on the test1
made readme.txt use CRLF for ease for windows users
Found some places where if things went horribly wrong, memory or file handles could potentially leak (this was actually very unlikely in practise, but best to be safe)
Now included prebuilt versions with zlib compiled in (STATICZ=1), so you can use that version if you don't want to rely on zlib1.dll or similar.
A couple of other minor changes I forget

Thanks everyone who made suggestions, and used the library

---------------------------------------
OLD MESSAGE:

I have done a bit of work on my PNG image library, the new version is available here:

http://www.streetcds.co.uk/fbpng_v1_8_4.tar.gz

New features:
Can now save PNG images.
No need to recompile to use OpenGL output anymore.
Improved codebase
Other changes.

Hopefully it's all covered in the readme.txt, but feel free to ask questions if you've got some.
Last edited by yetifoot on Jul 23, 2011 3:38, edited 8 times in total.
anonymous1337
Posts: 5494
Joined: Sep 12, 2005 20:06
Location: California

Post by anonymous1337 »

You can have me any time you want. Just keep the PNG coming. I've used PNG in almost every project of mine since you've released it. I've used PNG_LOAD to handle that format.
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Post by counting_pine »

Nice work.

I haven't tried saving PNGs with it yet, but I can't fault the PNG reading functions, and it's all very professionally finished off.

By the way, it's possible to get better results on the tests - use png2bmp -A -R to convert all the PNGs into BMPs with full alpha channels (BLOAD opens them fine). Then you can compare them directly, including the alpha channel, by just comparing the POINTs on each image buffer.
If you do that, it only fails on the three broken images.

Couple of miscellaneous comments:
The code uses relatively recent compiler features, so it won't compile in .16b.
Can you put CRLFs in the readme.txt file? Notepad chokes on the Unix-style line endings.
Would it be possible to give a default value forthe target parameter? In most cases, PNG_TARGET_FBOLD will be OK, and it would make the library a bit simpler to use.

I'm bitterly upset about you removing my line of code, by the way ;p
axipher
Posts: 891
Joined: Dec 27, 2005 16:37
Location: Sudbury,Ontario

Post by axipher »

I've loved this library in the past but it's giving me a hard time. I read the readme and copied the prebuilt libfbpng.a and fbpng.bi file to my programs directory but it gives me an "undefined reference to `png_load'" when I try to compile.
yetifoot
Posts: 1710
Joined: Sep 11, 2005 7:08
Location: England
Contact:

Post by yetifoot »

anonymous1337:

thanks

counting_pine:

thanks,

could you let me know what the compiler chokes on for you with 0.16? keeping 0.16 compatibility was an aim for the library, and i was able to compile and test it with 0.16 linux here, the only problem was a bug in 0.16 DIR on linux.

The suggestions about CRLF, a default target, and using png2bmp are good, but I won't make a new release just for them, they are fairly low priority.

For anyone who wants to change this themselves, if i remember correctly, wordpad will open unix files without a problem, then if you resave them they are in the regular format. For the default target just change the fbpng.bi to something like this:

Code: Select all

declare function png_load cdecl alias "png_load" _
	( _
		byref filename as string, _
		byval target   as png_target_e = PNG_TARGET_FBOLD _
	) as any ptr
Axipher:

Sorry you had a problem, I've realised that i missed a line out of the fbpng.bi header.

where the code says this in fbpng.bi

Code: Select all

#ifdef PNG_DEBUG
#include once "fbmld.bi"
#endif
Just below it add,

Code: Select all

#inclib "fbpng"
either that, or when you compile, add to the command line
-l fbpng
Hopefully that should solve any linking errors
axipher
Posts: 891
Joined: Dec 27, 2005 16:37
Location: Sudbury,Ontario

Post by axipher »

Yep, that did it, how did I not notice that missing line. All works now though, for some reason PNG's rotate better then BMP's with MULTIPUT, very weird. Thanks again. :)
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Post by counting_pine »

OK, FBC 0.16b is choking on it because:

"= any" is used a lot in the code. Perhaps you could change them all to "any_" or something, and define that in a header as either 0 or any, depending on the build date. (In fact, the __fb_build_date__ define was added after "= any", so you could just check whether it's defined or not.)
Or, of course, you could just remove them all.

You use uLong in a header, but that keyword was only added recently. You could TYPE that as Unsigned Long if it's not already defined, or just do a Find and Replace.

In png_image_convert.bas (lines 188-189), you've got a couple of duplicate definitions, max and mask. You dimmed them earlier but it's legal in 0.17b, I guess because of the Scope rules. (I'm surprised 0.16b would have a problem with it.)
EDIT: Turns out my 0.16b build wasn't final for some reason, evidently it predated the new scoping (I think the other things still stand).
Still, worth fixing. Perhaps the new FBC should have a switch that warns you of variable name reuse:)

Anyway, if I fix all that, then it compiles OK.

EDIT: @axipher, what do you mean, exactly? Once an image is loaded, it shouldn't matter where it came from.
Last edited by counting_pine on Apr 18, 2007 1:45, edited 1 time in total.
axipher
Posts: 891
Joined: Dec 27, 2005 16:37
Location: Sudbury,Ontario

Post by axipher »

Well I opened a PNG in paint and saved as BMP, now pixel for pixel they were the exact same image once loaded into FB, but the BMP became much more blocky when rotated with MULTIPUT then the PNG when rotated with MULTIPUT. Not sure why, but it just happens that way.
counting_pine
Site Admin
Posts: 6323
Joined: Jul 05, 2005 17:32
Location: Manchester, Lancs

Post by counting_pine »

Interesting... Can you post any code/screenshots so we can see what you mean?
Well, I've never really used multiput before but I've had a quick look at it now, and I think it might be its new/old header reading code.
Are you using the CVS FB? Since the last testing release, the header format has changed. Both forms are still valid, but imagecreate will be using the new header, while png_load, with the PNG_TARGET_FBOLD target, will be using the old header. If there's something wrong with the header reading code, MultiPut might work better with the old header than the new header.

If you are using CVS, try changing the target to PNG_TARGET_FBNEW. Does that have any effect?
axipher
Posts: 891
Joined: Dec 27, 2005 16:37
Location: Sudbury,Ontario

Post by axipher »

Well I'm using CVS and I'm loading the PNG's with PNG_TARGET_FBNEW, I figured that much out. It's not much of a difference, I'm going over my code now to check if it's something else.

BTW: does anyone know a better way to rotate an image, MULTIPUT is very choppy and my attempts at a rotator aren't any better, yet Adobe Photoshop CS2 does a superb job and makes it look perfect.
D.J.Peters
Posts: 8586
Joined: May 28, 2005 3:28
Contact:

Post by D.J.Peters »

hi axipher
multiput was for fast sprites not fine image processing.
rotate every pixel with sin/cos and you will get a nice looking image.

Joshy
Zamaster
Posts: 1025
Joined: Jun 20, 2005 21:40
Contact:

Post by Zamaster »

@axipher

Photoshop does a good job becuase it antialiases the image after rotation. You dont absolutely have to rotate every pixel by SIN and COS, texture mapping a quad is a slightly slower but attractive way to achieve the results youre looking for.
axipher
Posts: 891
Joined: Dec 27, 2005 16:37
Location: Sudbury,Ontario

Post by axipher »

Well the sin/cos method is probably what I'll end up doing, but the images are just PNG's max size of 64x64, so texture mapping may be a good idea, before I go searching for algos, anyone have a basic texture mapper that would fit my needs?
TbbW
Posts: 348
Joined: Aug 19, 2005 10:08
Contact:

Post by TbbW »

KICKASS MAN!

iwe used png_load alot coz png format is way better then bmp.
but i have missed the function of saving png's from a buffer... u just made it all true ^^

keep up the good work!
DOS386
Posts: 798
Joined: Jul 02, 2005 20:55

PNG

Post by DOS386 »

I have done a bit of work on my PNG image library, the new version is available here
Looks good. I wonder whether there is an easy way (one can always implement from RFC's) to get it working in DOS, without full DJGPP install ?
Post Reply