Re: std.zlib odd behavior
On Wednesday, 6 March 2019 at 01:50:16 UTC, solidstate1991 wrote: Thanks, it seems I'll have to write my own solution for this, and I really dislike the way streaming compression works in C. I've spotted some other bugs regarding my PNG implementation, but those were unrelated and didn't improve the compression issues. I was finally able to tame the beast, now I can load and save PNG files. Now I probably have issues with standardization, which will require me to read up on the topic, since my output isn't liked by IrfanView, and many other applications.
Re: std.zlib odd behavior
On Tuesday, 5 March 2019 at 02:19:26 UTC, Adam D. Ruppe wrote: I haven't found the bug in your code yet, but one thing I suspect from my experience is you might be reusing a buffer. std.zlib actually stores pointers internally across function calls, so if you are trying to compress a stream, you are liable to get corruption. (std.zlib is very bad code, frankly.) I don't know for sure though, my brain is in the compiler tonight... Thanks, it seems I'll have to write my own solution for this, and I really dislike the way streaming compression works in C. I've spotted some other bugs regarding my PNG implementation, but those were unrelated and didn't improve the compression issues.
Re: std.zlib odd behavior
On Tuesday, 5 March 2019 at 01:43:42 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/dimage/blob/master/source/dimage/png.d It seems that after a certain point, it doesn't add more data to the compression stream, flushing doesn't help. What do you mean by "doesn't add"? ubyte[] slice = pos < imageData.length ? imageData[pos..(pos + pitch)] : imageData[pos..$]; This can't possibly work. You slice past the end of array.
Re: std.zlib odd behavior
On Tuesday, 5 March 2019 at 01:43:42 UTC, solidstate1991 wrote: https://github.com/ZILtoid1991/dimage/blob/master/source/dimage/png.d It seems that after a certain point, it doesn't add more data to the compression stream, flushing doesn't help. I haven't found the bug in your code yet, but one thing I suspect from my experience is you might be reusing a buffer. std.zlib actually stores pointers internally across function calls, so if you are trying to compress a stream, you are liable to get corruption. (std.zlib is very bad code, frankly.) I don't know for sure though, my brain is in the compiler tonight...
std.zlib odd behavior
https://github.com/ZILtoid1991/dimage/blob/master/source/dimage/png.d It seems that after a certain point, it doesn't add more data to the compression stream, flushing doesn't help.
