LabVIEW
How can I create huge size PNG file with drawing?
Is size the only problem or do you have problems drawing a circle?
Is this black&white? Is the circle filled? How thick is the outline?
What's the purpose of this file? What program is supposed to open and render it later?
Does it have to be a single file or could you draw a series of tiles instead?
Are you planning to use the image tools and png write or are you planning to write all low-level file structures?
That's almost 6 GBi (at 4 bytes per pixel). Is the PC running out of memory, or is LabVIEW running out of memory?
At least tell me you use 64 bit LabVIEW! That will help, but not solve things.
One way out would be to make a 200KX8K uncompressed PNG (if that exists, but they are quite flexible), and figure out a way to replace pixels in the file. That will be tricky, but might just work.
Or, make your own PNG generator that streams PNG data as it comes. That would require intimate knowledge of the PNG format, but the compression could probably be done streaming. Provided the data can be generated left to right, top to bottom, which is feasible for a circle (simply check if (x-x0)^2+(y-y0)^2>r^2 ).
Smells like computer generated holographics? Writing Fresnel patterns? Just curious..
Search LabVIEW like a graph! 
If you read http://www.libpng.org/pub/png/spec/1.1/PNG-Structure.html and compare to a simple uncompressed Picture as the one i attach, it should be possible to write a PNG file of your own, and then it should be fairly straiht forward.
I wandered if 0 compression means "no compression" or "lossless compression".
If 0 means "lossless", I'd still expect some deflating, or at least run length encoding to happen. But maybe not...
@Yamaeda wrote:
If you read http://www.libpng.org/pub/png/spec/1.1/PNG-Structure.html and compare to a simple uncompressed Picture as the one i attach, it should be possible to write a PNG file of your own, and then it should be fairly straiht forward.
The old badge in your sig reminds me of how LV has cheapened the whole cert process by making the new badges look like unlocking an achievement in a video game. My achievement (arguably) took a lot more effort than "Achievement Unlocked: Kill all your enemies in stealth mode." in game X.
I know that was the intent, but I didn't agree with it then; I don't agree with it now.
wiebe@CARYA wrote:
I wandered if 0 compression means "no compression" or "lossless compression".
If 0 means "lossless", I'd still expect some deflating, or at least run length encoding to happen. But maybe not...
As far as I know all PNG is lossless. 0 means no compression, just a few bytes for overhead. No run length, no huffman tree, no LZ77. 1 means the least amount of compression, but still lossless.
No compression. My example vi also shows it if you look at the resulting file, it's pretty similar to a BMP.
@Yamaeda wrote:
No compression. My example vi also shows it if you look at the resulting file, it's pretty similar to a BMP.
You are not talking about the same as Altenbach. You talk about the compression input to the PNG VI, Altenbach is talking about the compression byte in the PNG IHDR chunk. The compression byte in the IHDR chunk has currently only one possible officially defined value and that is 0. It means that the data is compressed with the zlib deflate algorithme.
The actual IDAT chunks that contain the image data start with a zlib header that contains the compression flags which indicate the actual zlib compression method (standard requires here 8 for deflate algorithme), and compression level. This compression level is what the PNG VI allows to set.
