How can I create huge size PNG file with drawing?

[wiebe@CARYA]

I can now create a PNG from a 32 bit pixmap (that I read from a PNG).

So the argb values aren't swapped, but rotated. So argb->rgba.

Each scanline seems to begin with a 0. Can't find this in the documentation, but it doesn't work without it.

Now I need a way to either fake the deflate header\footer, or find a way to do a streaming deflate.

[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.

---

Sorry, but 'your' CRC is only the same as the Deflate's CRC for small strings.

For larger strings, the CRC is different. I think Deflate is right 😉...

[wiebe@CARYA]

---

wiebe@CARYA wrote:

---

@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.

---

Sorry, but 'your' CRC is only the same as the Deflate's CRC for small strings.

For larger strings, the CRC is different. I think Deflate is right 😉...

---

This one does...

Saved back to LV11, because... why not.

[wiebe@CARYA]

Next hurdle is probably that Deflate has a 32k size limit...

[Hooovahh]

---

wiebe@CARYA wrote:

---

---

This one does...

Saved back to LV11, because... why not.

---

Oh man thanks. Please no one use my version, it clearly has issues.

[Jaeryul-Gosan]

I think your opinion is correct.
However, when I first created an image, it was difficult to calculate the array and create a random position and size.
So I used the IMAQ Draw function to create a detached image first.
Then what I'm trying to do is convert the BMP to Byte and then modify the header and pixel data.
But I don't seem to understand the format of BMP well.
Also, I'm not sure if these methods will enable image processing in less memory.

[Jaeryul-Gosan]

Also I tried to stream data by referring to that example.
Is it suitable?

http://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/stream_data_spreadsheet/

[wiebe@CARYA]

---

@Jaeryul-Gosan wrote:

Also I tried to stream data by referring to that example.
Is it suitable?

http://zone.ni.com/reference/en-XX/help/371361R-01/lvhowto/stream_data_spreadsheet/

---

Streaming would do the trick. But you need to stream the correct data, so the data matches the spec of .bmp or .pgn. And that's not that easy.

[wiebe@CARYA]

Oh boy. This one isn't easy.

Couldn't let it go, even sitting inside during my holydays (procrastinating filling in last weeks hour sheets 😁).

The attached library creates a PNG with a background color, and then lets you manipulate pixels.

The example 'draws' random circles, by looping over each pixel, and checking if it's in or out. this is very inefficient, but should work for an example. It would make more sense to take each circle's center, and draw a circle around it... Or use Breshenham's circle algorithm...

After that, the zlib CRCs and the idat PNG chunk CRC needs to be recalculated.

This seems to work for large PNGs. I've tested 100000X1000. Don't expect any speed though. Looping over the pixels takes for ever! Well, several minutes anyway.

I'm surprised most tools seem to handle 100000X1000 pixels just fine. LabVIEW doesn't allow it, although that could be a CRC error (LabVIEW is picky on the CRC, while other programs simply ignore CRC errors).

To go to 200000X8000, another threshold needs to be crossed. The size crosses the 32 bit barrier. That means it won't fit one idat chunk... It won't be too hard to modify the given code though. 

I can't say everything was mapped to specification (can't find a description of the deflate header). I'm sure there will be issues.

Have fun!

[Jaeryul-Gosan]

---

wiebe@CARYA  작성:

Oh boy. This one isn't easy.

Couldn't let it go, even sitting inside during my holydays (procrastinating filling in last weeks hour sheets 😁).

The attached library creates a PNG with a background color, and then lets you manipulate pixels.

The example 'draws' random circles, by looping over each pixel, and checking if it's in or out. this is very inefficient, but should work for an example. It would make more sense to take each circle's center, and draw a circle around it... Or use Breshenham's circle algorithm...

After that, the zlib CRCs and the idat PNG chunk CRC needs to be recalculated.

This seems to work for large PNGs. I've tested 100000X1000. Don't expect any speed though. Looping over the pixels takes for ever! Well, several minutes anyway.

I'm surprised most tools seem to handle 100000X1000 pixels just fine. LabVIEW doesn't allow it, although that could be a CRC error (LabVIEW is picky on the CRC, while other programs simply ignore CRC errors).

To go to 200000X8000, another threshold needs to be crossed. The size crosses the 32 bit barrier. That means it won't fit one idat chunk... It won't be too hard to modify the given code though. 

I can't say everything was mapped to specification (can't find a description of the deflate header). I'm sure there will be issues.

Have fun!

---

How can I understand your program?
Do I need to learn more about the PNG file format?

I was trying to combine files separated into BMP files rather than PNG files, but the file size header is 4 bits, so files up to 4 GB can be made with standard headers. Because of this, I try to use a format other than the BMP format.

So, after learning about the format, do I have to make an encoder and a decoder?

Below is a divided BMP image. (The previous image was created incorrectly.)

https://drive.google.com/drive/folders/1NUBaPpEXWV-IUEoQxSdbEfI3l2ZeWJrZ?usp=sharing