LabVIEW
How can I create huge size PNG file with drawing?
Is OP still following this? Some feedback on the line of though we're exploring would be nice.
I think it is fair to say PNG can have uncompressed lossless data, so the idea to create a file and fill it, or to stream to the file to fill it will work.
Whether LV can create those PNGs doesn't really matter. I'd expect LV to fail anyway because of the size. Perhaps LV can do the ground work, and we can grow the data from that.
I'd also be suspicious about the resulting file. Do consumer programs accept 6 GB PNG files? Would we be able to test the result?
If it was a binary image, I'd be more optimistic. The file would still be 200 MB, which seems 'reasonable'.
Search LabVIEW like a graph! 
@rolfk wrote:
@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.
You're right, we did talk about different things. However, using a 0 in the Write to PNG it sure looks like the data is uncompressed as the Picture i posted only results in two different data values in an approximate amount matching the number of pixels (i didn't analyze too Deep), whereas some compression would result in some advanced pattern of data.
@Yamaeda wrote:
@rolfk wrote:
@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.
You're right, we did talk about different things. However, using a 0 in the Write to PNG it sure looks like the data is uncompressed as the Picture i posted only results in two different data values in an approximate amount matching the number of pixels (i didn't analyze too Deep), whereas some compression would result in some advanced pattern of data.
I get the same results.
Loading a PNG, the image data bytes is present in the PNG file (compression 0), uncompressed and lossless.
This will potentially make things a lot easier (until the next hurdle).
@Yamaeda wrote:
You're right, we did talk about different things. However, using a 0 in the Write to PNG it sure looks like the data is uncompressed as the Picture i posted only results in two different data values in an approximate amount matching the number of pixels (i didn't analyze too Deep), whereas some compression would result in some advanced pattern of data.
That's expected. A zlib deflate compression level of 0 basically means that the data is simply put in the byte stream (and a 32-bit CRC is appended too, although some decoders will not verify it for this compression level). There still is of course the zlib data header before every stream and the PNG files chunk structure needs to be properly adhered to, but the image data bytes are not altered. The PNG chunking does however make it a little bit tricky to locate the image data chunks in the file. For instance PNG specifically says that a decoder is not allowed to make any assumptions that any IDAT chunk corresponds to a specific line boundary or anything. Simply that one or more IDAT frames together will contain the entire bitmap data.
Maybe you can use a Zlib library to create the data with CRC? Since a chunk can be 2^31 bytes there's no requirement to chunk it up, and in my PNG it all seems to be a single chunk. Maybe it's an effect of not being compressed.
@Yamaeda wrote:
Maybe you can use a Zlib library to create the data with CRC? Since a chunk can be 2^31 bytes there's no requirement to chunk it up, and in my PNG it all seems to be a single chunk. Maybe it's an effect of not being compressed.
I think zlib will be the easiest. Not sure if the zlib CRC is trivial.
Other then this, it's quite simple.
@Yamaeda wrote:
Maybe you can use a Zlib library to create the data with CRC? Since a chunk can be 2^31 bytes there's no requirement to chunk it up, and in my PNG it all seems to be a single chunk. Maybe it's an effect of not being compressed.
The OpenG ZIP library exposes the deflate, inflate and crc32 routines from the underlaying zlib library.
The zlib crc seems to be the same as the PNG crc used for the chunk headers. That makes sense, as zlib has it's origins in libpng...
However, I don't get the same crc after the first try.
EDIT: also can't get the zlib CRC and the PNG CRC to match. Guess this it's that simple.
wiebe@CARYA wrote:
The zlib crc seems to be the same as the PNG crc used for the chunk headers. That makes sense, as zlib has it's origins in libpng...
However, I don't get the same crc after the first try.
No! The PNG specification specifically states that they are NOT the same.
@rolfk wrote:
wiebe@CARYA wrote:
The zlib crc seems to be the same as the PNG crc used for the chunk headers. That makes sense, as zlib has it's origins in libpng...
However, I don't get the same crc after the first try.
No! The PNG specification specifically states that they are NOT the same.
OK. I looked at the gzip crc, and expected those to be the same. They do use the same magic numbers.
My edit crossed. The zlib CRC and the PNG CRC of the deflated data also don't match.
Guess it's time for me to focus on my problems...
