How can I create huge size PNG file with drawing?

[Hooovahh]

If you haven't discovered this yet, the zlib deflate or rather RFC1951, uses an Adler-32 CRC, on the uncompressed data.  Attached is a VI I wrote recently that I believe performs this CRC.

[Jaeryul-Gosan]

Thanks for everyone.

Firstly I Tried to made Image first and did it.

Now I need Stitch all image together.

After any progress I do I will reply again.

[Jaeryul-Gosan]

And here is sample image I did made.

https://drive.google.com/drive/folders/1gVF3uTbRgsx-TvkoCP-11f6g_nmmBPp2?usp=sharing

[Jaeryul-Gosan]

I am using LabView 32bit and the image creation succeeded in my current situation. However, I did it by dividing the image creation. So I need to write a program to make these images one.

https://drive.google.com/drive/folders/1gVF3uTbRgsx-TvkoCP-11f6g_nmmBPp2?usp=sharinghttps://forums.n...

[wiebe@CARYA]

---

@Jaeryul-Gosan wrote:

 So I need to write a program to make these images one.

---

To me, that seems much harder than making a large image from scratch...

[wiebe@CARYA]

---

@Hooovahh wrote:

If you haven't discovered this yet, the zlib deflate or rather RFC1951, uses an Adler-32 CRC, on the uncompressed data.  Attached is a VI I wrote recently that I believe performs this CRC.

---

Now I have 4 different CRC results:

• The LabVIEW PNG File CRC of the image data.
• The zlib deflate CRC of the image data
• The PNG chunk CRC of the image data
• Your CRC of the image data.

All give different values!

So somehow I'd need to eliminate things (I won't try the PNG chunk CRC). I think either:

• (some) CRC calculations are off.
• the data I feed the CRC is wrong (or incomplete).
• two CRCs that are different are both are correct.

I won't rule out the latter yet. If results are wrong, it could be anything.

[wiebe@CARYA]

Some things to consider...

LabVIEW doesn't really work with 32 bit images, unless you load one. Picture To Pixmap uses 24 bit images, even if you specify 32 bit. This causes complications, as padding is added in the PNG (I think).

The data in the PNG has the bytes in reversed order. So the "image" in a Pixmap needs to be converted to U32s, byte swapped, word swapped, then casted to a string\byte array to be CRC-ed.

[Yamaeda]

@wiebe@carya it doesn't seem to be padded. In my test Picture the binary reads 00 41DC 0041 DC00 41DC 0041 DC00 41DC 00 at the blue section, which seems like 3 bytes repeated of 00 41 DC which is a dark blue.

[wiebe@CARYA]

---

@Yamaeda wrote:

@wiebe@carya it doesn't seem to be padded. In my test Picture the binary reads 00 41DC 0041 DC00 41DC 0041 DC00 41DC 00 at the blue section, which seems like 3 bytes repeated of 00 41 DC which is a dark blue.

---

With an empty image, I get all 0xFF as image data, but in the PNG there are 00.

I still see it with 32 bit images, so it probably isn't padding. Probably the "no compression", chunking things up.

[wiebe@CARYA]

I finally got some consensus.

I tried to match the the deflate stream's header with the CRC. The first two bytes of the CRC (Hooovahh's) are added on the back of the deflate stream.

A read of the manual would have told me that... Maybe not as fast though.

I think creating a file, and then changing bytes will be hard. Who knows what formatting the deflate added to the raw data? Will it be consistent?

Steaming the file is still feasible. I think I did a streaming deflate at some point. Perhaps I mixed it up with LV's zip functions, that are streaming under the hood. I'll have to search for it.