. /../PNG image exporter/ 12
kamikazemadman
written by Peterpaul kl h on Oct 30, 2004 20:00
Just before the weekend i promised Cryo that i would release a first beta release of the PNG image save library. But unfortunately there were some bugs that i introduced the last time when i was trying to fix others. But i've found an earlier copy, which i will release right now. Note that this is also the code that i will start developing and bugfixing from now. The buggy code will be deleted.

Anyway, you can download the code, along with the reborn png test application (+ source) from cd/zips/Peterpaul kl h/png (91 Kb). This package can be regarded as a complete PNG package, since the reading library is also included, infact the pngsave library needs the normal png library at the moment. Though this might change in the future.

This package lacks a few things: proper documentation being the most important one and also the libraries are not fully working. There can be more optimizations in both execution speed, and in compression ratio. But this is worked on. Please note that currently compression is only reliable with the options:
- DEFLATE NO COMPRESSION
- DEFLATE FIXED HUFFMAN CODES
I'm trying to fix a bug in the DEFLATE DYNAMIC HUFFMAN CODES option, which would result in better compression ratio.

Anyway, have fun, ask/tell me anything you think is important.

PS You might notice that some libraries changed their place inside my libraries folder. This is because i'm rearranging things some more.
written by Yeoh on Oct 30, 2004 22:24
Hi Peterpaul,

Thanks for releasing this new beta version. pngtst.txt compiled okay with Linoleum 1.14 alpha. Tested loading a PNG and saving to a new PNG file. And re-loaded the new PNG file, okay.

Very good work.

Best Regards,
Yeoh
--
kamikazemadman
written by Peterpaul kl h on Oct 31, 2004 06:59
Thanks, i'll try to make it even better .
halp! tail!
written by Alex on Oct 31, 2004 08:24
Wow, Peterpaul!
You... you... you!
You simply are what you are

mmmh... 1.14 alpha...
more like a "1.13 and a half"
written by Yeoh on Oct 31, 2004 12:56
Alex said:
mmmh... 1.14 alpha...
more like a "1.13 and a half"
much improvement over 1.13! Now, eagerly awaiting 1.14.
written by Bracx on Oct 31, 2004 14:09
Nice library, Thank you!

Yeoh said:
much improvement over 1.13! Now, eagerly awaiting 1.14.
I have not tried the 1.14 alpha yet. Am I missing anything, or should I just wait till 1.14 to upgrade?
kamikazemadman
written by Peterpaul kl h on Oct 31, 2004 18:50
Alex said:
Wow, Peterpaul!
You... you... you!
You simply are what you are
Yeah, i guess everyone would agree on that one .
Bracx said:
I have not tried the 1.14 alpha yet. Am I missing anything, or should I just wait till 1.14 to upgrade?
Well, you could start using 1.14 alpha to get used to at least some of the new things 1.14 will introduce. There are quite a few extension to the linoleum language, while being backward compatible with 1.13 and before....
Okay, except for not allowing underscore characters in identifiers.
And the compilation speed is much higher compared to 1.13 which is probably one of the things you'll notice most.
written by Yeoh on Nov 01, 2004 00:38
Bracx said:
I have not tried the 1.14 alpha yet. Am I missing anything, or should I just wait till 1.14 to upgrade?
1.14 alpha is a visual compiler. Instead of the DOS box in 1.13 , you can see an iGUI client when you compile your linoleum apps.
Most important--it compiles much faster than 1.13. It compiles all the examples without any problems. I'm glad I switched to 1.14 alpha after a day or two using 1.13.
written by Cryoburner on Nov 02, 2004 08:14
The exporter part seems to work fine so far. Nice work! : )

I should note that there seems to be a bug in the png loader though, which doesn't properly load the bottom part of a certain image. You can find the file in question here...
cd/pngs/Cryoburner/nutritios_sm (109 Kb)

Also, I seem to have a strange problem where a certain png image file doesn't appear in the directory listing, although that might be caused by a glitch in iGUI. If copied to another folder, it appears in the list fine, and other images appear within its directory as well.

Anyway, all of the other files I attempted to load, as well as those I saved, worked so far. I hope to see further improvements as they become available. : )
kamikazemadman
written by Peterpaul kl h on Nov 02, 2004 11:28
Cryoburner said:
I should note that there seems to be a bug in the png loader though, which doesn't properly load the bottom part of a certain image. You can find the file in question here...
cd/pngs/Cryoburner/nutritios_sm (109 Kb)
Hmmm, and other applications load that file when saved with the exporter completely? Because i've only seen such a bug with the dynamic huffman codes so far, but then also gimp or exporer or mozilla load only half or just a percentage of the file.

But, since you supplied the file yourself i'll look to this png image later on today.
Thanks for the comments, and i'll hope to improve this library some more!
written by Cryoburner on Nov 02, 2004 12:00
Oh, the image was made in Photoshop, and not resaved with your test app. The problem isn't with encoding, but with the decoding. Also, I just tested it with an older version of the PNG loader, and the file loads fine, so it must be something you've since changed. Another thing worth mentioning is that the file decompression time seems to be a bit slower. Did you happen to change anything major with that?
kamikazemadman
written by Peterpaul kl h on Nov 02, 2004 15:06
Ah I see. Then i expect the problem to be in the zlib library, because i changed some things in there because i needed certain functionality which was part of routine, but is now a routine itself. And i tried to do some more checks to prevent invalid memory accesses.

For the loader to seem slower. I noticed that the console library really slows an application down, even if the console isn't visible. Therefor i added the option to disable text output from the png loader. Please try again with output disabled and if you still notice a slowdown, please let me know. I'll also look into that, so perhaps we can find the problem.

PS: At the moment i'm working on my own memory manager, which will be a replacement for both Vladimir's lock library as my dynaheap library. This library doesn't need an initialization, but will work on the first call to "malloc". Also i'm trying to keep it fast and optimize it. The fun thing for this library is that the information needed to manage the available space is also managed by the library itself. And using this as an object allows to replace this and the routines with more efficient ones. Currently it uses a sorted list, which finds objects in O(log n) and adds objects in O(n), where n is the number of free blocks. But if i could make this a hashmap, both could be achieved in constant time! Anyway, back to work
written by Cryoburner on Mar 04, 2006 16:13
This isn't directly related to the exporter, but rather to the png loader, although the thread for that appears to be in the members projects section, so this seems more fitting. I'm having an issue with loading some png files in a program, and decided to make a minimal test program to see what was wrong. Unfortunately, I'm having the same issue there as well. The programs work fine using Lino's tga loader library, but switching them over to the png loader results in the load process failing, with no image data written to the target layer. It shouldn't be a problem with the png files either, since the test program included with the library appears to load them correctly.

I did notice that the png tester included with the library is using a newer version of Peterpaul's libraries than are found in the Lino 1.2 preview package, although attempting to use those results in the program crashing at runtime, which is worse than just not displaying anything at all. Does anyone know how to get the png loader to function correctly in this simple test program? I've included the test program, along with the nearly identical tga version which works correctly.

cd/zips/Cryoburner/testpng (44 Kb)

I've gone back to using uncompressed tga files in that project for now, and likely won't even use pngs for it, since the file size shouldn't be very different when zipped anyway. The tgas also load quicker, although they obviously require more hard drive space. I would still like to get this test program working though, since I don't see why it shouldn't work. : )
written by Cryoburner on Mar 09, 2006 07:14
Hmm... no replies yet. : )

Anyway, I just thought I'd post this here, since I don't think it requires its own thread. I added support for 8 bit grayscale images to the TGA loader, as they are slightly smaller than indexed ones. If a bunch of tiny grayscale images need to be used for something, the size difference could add up, and there's little reason not to support them when it only requires adding around 12 lines of code. : P

Anyway, you can find my updated version of the library here, with my additions pointed out by () marks...
cd/zips/Cryoburner/tga mod (5 Kb)
kamikazemadman
written by Peterpaul kl h on Mar 09, 2006 10:41
Well, i was going to reply, but i forgot. Lately i've been very busy. I'll try and see if i can make this work.

[edit]
Ok, the first thing is that for some reason the PNG library fails to load the image. This can be checked with:
? failed -> error handler;

[edit2]
Ah, ofcourse, the png library needs the lock library to dynamically allocate the memory it needs for uncompressing of the compressed png image data. So, before calling the function, initialize the lock library. I'll adjust your code for simplicity.
└> last changed by Peterpaul kl h on March 09, 2006 at 11:25
reading this thread
no members are reading this thread
. /../PNG image exporter/ 12
42515, 18 queries, 0.204 s.this frame is part of the AnyNowhere network