CRC-32 field in zip - c

I am designing a zip-unzip utility using C. There is a crc-32 code field. Is it of compressed data or uncompressed data?

It is the CRC-32 of the uncompressed data. In other words, it would be the CRC-32 of the file's original contents before being compressed. Zlib has a minizip contribution which is a small zip/unzip implementation written in C. In zip.c you can see in the function zipWriteInFileInZip that it is generating the crc of the buffer passed in that should contain the file's original contents.

Related

PNG IDAT chunk data calculation

I'm trying for learning propose to write my own png file in c language.
I have already read the PNG file format specification and i am now able to write a basic PNG(signature, IHDR CHUNK, 1px-IDAT CHUNK AND IEND CHUNK).
But now i want to write a array of pixels into the PNG, all chunks are going okk but I don't understand how to generate the IDAT data CHUNK.
In libPNG documentation they explain to deflate() the scanline, preced by the filer byte method.
My understanding of this problem:
A scanline is an array of horizontal pixels preceded by the filter method(0) then of size: (3*screenWidth + 1)
for each line (screenHeight value), I compress() the scanline with zlib and store it in a file.
But After generating the png, it is always black and the value is always 0 in hex editor.
what am i doing wrong? or is the the good way to generate IDAT data values?
You did not put any code in your question, so we have no way of knowing what you're actually doing. "I compress() the scanline with zlib and store it in a file." sounds wrong. You need to assemble all of the scan lines as described, and then compress the entire thing with zlib, once.

Deflate Format: differences between type blocks

I am currently trying to write a compressor and decompressor with the same purpose as the RFC Deflate specification.
I'm not able to understand the difference between how blocks are composed in the compression with fixed tables and dynamic tables. The file is processed by LZ77 generating (distance, length) + literal.
How do I know the type of block?
Do I have to compress this data?
Given that I use a fixed compression and don't have to send the tables, how would the encoder know how to encode data?
Moreover, do I have to send data before the actual compression executes?
I am confused on the difference between fixed tables and the table we send in the dynamic mode, and how the two blocks use them to encode data.
I'm currently reading Data Compression: The Complete Reference. Any advice will be helpful.
Since you are trying to compress, you would pick the smaller of the two. zlib's deflate computes what the size of a fixed block, a dynamic block, and a stored block would be, and emits the smallest of the three.
If you are encoding a fixed block, you encode using the fixed code for literal/lengths and distances. This code is provided in the RFC.

How to estimate progress of decompress of bzip2 file using C function?

I could use gzoffset function in zlib to estimate the remaining uncompress file size. Is there a similar function in bzip2 library? If not, is there any trick that I can use?
Just track the amount of compressed data consumed. When you have processed xx% of the compressed data, you have generated approximately xx% of the uncompressed data.
gzoffset() does not tell you anything about the remaining uncompressed file size. It only tells you how many bytes you have uncompressed so far. You can get that simply by counting how many bytes you have uncompressed so far.

how to take a JPEG out of IplImage* and not saving it to hard drive put saved dat into char*?

So what I need is simple: I have IplImage* I want to encode it into JPEG and wrap it with some additional JPEG data if needed (JPEG files contain noty only encoded pixels) and put tha file (not saved onto hard drive) into char* buffer. How to do such thing?
JPEG is a complex format. You can use the IJG jpeg library as a base to work with. However, be warned, it is a mess in itself and has a slight learning curve. It is open source, and you'll typically need to configure its build according to your compiler using a provided makefile (which may not be found with the library code itself)

Array Compression Algorithm

I have an array of 10345 bytes, I want to compress the array and then decompress, kindly suggest me the compression algorithm which can reduce the size of array. I am using c language, and the array is of unsigned char type.
Rephrased: Can someone suggest a general-purpose compression algorithm (or library) for C/C++?
zlib
Lossless Compression Algorithms
This post's a community wiki. I don't want any points for this -- I've already voted to close the question.
The number of bytes to compress has very little to do with choice of compression algorithm, although it does affect the implementation. For example, when you have fewer than 2^15 bytes to compress, if you are using ZLib, you will want to specify a compression-level of less than 15. The compression-level in Zlib (one of the two such parameters) controls the depth of the "look-back" dictionary. If your file is shorter than 16k bytes, then a 32k look-back dictionary will never half-fill; in that case, use one less bit of pointer into the look-back for a 1/15th edge on the compression compared to setting ZLib to "max."
The content of the data is what matters. If you are sending images with mostly background, then you might want Run Length Encoding (used by Windows .BMP, for example).
If you are sending mostly English text, than you wish you could use something like ZLib, which implements Huffman encoding and LZW-style look-back dictionary compression.
If your data has been encrypted, then attempting to compress it will not succeed.
If your data is a particular type of signal, and you can tolerate some loss of detail, then you may want to transform it into frequency space and send only the principal components. (e.g., JPEG, MP3)

Resources