New version of PNG library (now v1.9.4)

yetifoot · Master

Latest version

OK, I upped a new version:

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

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;

Pritchard · Guru

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

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 · Master

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 · Master

pritchard:

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:

axipher · Master

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

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.

axipher · Master

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

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 · Master

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 · Guru

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 · Master

@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 · Master

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 · Sr. Member

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 · Sr. Member