Zlib Compression - PNG Fatal Error

[LunaRebirth]

Hi,

I'm using Zlib to compress a file and send it over sockets.
Specifically from https://gist.github.com/gomons/9d446024 ... 84e29e154a.
Once the client receives the compressed file and decompresses it, I can open the image in Windows Image Viewer, Paint.NET, and any other software.

However, Irrlicht won't open draw it.
I get "PNG Fatal Error: Read Error"

Why might Irrlicht be doing this, and what should I do to try to fix it?

Note that sending other files, such as WAV files to be played by OpenAL, are working and loading just fine.

Thanks

[devsh]

Woah dude, we need to see a bit more code in that gist.

The thing which throws red flags for me is that std::string which is not used carefully on an arbitrary byte buffers could result in truncation from a single 0 byte in your buffer.
(however it won't in your gist because your std::string::append is sized, and you're debugging out the sizes, so I'd guess you'd notice)

How do you read the texture/file, do you create an IReadFile from the memory?

Note that most compression libraries pad certain buffers to become nice round multiplies of some magic constant, so you should most probably send the original buffer/file size too.

Also, have you checked that the decompressed data is 1:1 byte-for-byte identical (content and length) with the data you'd have read from disk???

[CuteAlien]

Try to locate first where the error really happens.
Does the zip load when you do not send it over the net?
What when compressing and not sending it over the net?
What about sending it uncompressed over the net?

[LunaRebirth]

I tried to remove this post last night, or at least update it to say it was my own problem, but the site went down

The files weren't identical, but I am still curious why every program I tried could open the files except Irrlicht

[CuteAlien]

Once things are messed up anything can happen. Don't think too much about it :-)

[MartinVee]

Since you asked...

Some program or library may decompress the zlib'ed file in chunk, and try to display the chunks individually, instead of stopping the entire process on a bad chunk. Since a PNG is pretty much a zlib'ed BMP, each valid chunk will hold valid bitmap data. And for each invalid chunk, you may still have a valid IHDR width and height, which would enable the rendering of "something". That "something" may be noise, repeating of the last chunk, random colors, ... name it, that entierly depends on the implementation.

So, you may end up with something that closely (or not) looks like the original image. That may or may not be what you want.

Personnaly, since in my line of work all graphical assets have to go through a rigorous approval process, I don't want Irrlicht to render it "close enough". If the asset is bad, then it's bad. I need to fix that.

So, again personnaly, I'm good with Irrlicht not displaying it. But I can understand why a program like Irfanview (for example) would try to display a PNG as best at it can, even if a chunk or two are wrong. After all, you don't want to loose an picture of an important moment just for a byte or two of corruption.

[LunaRebirth]

Thanks for the detailed explanation, that makes sense why you would not want to display an "almost good enough" image.