0

I have a problem uncompressing a file that should be compressed atm with zlib. The file is a icecache file

This is from the documentation:

Cache files are created on a per object and per frame basis. Each file is a zip archive, utilizing the ZLIB library to save and load directly using a zip-stream. located at: http://softimage.wiki.softimage.com/index.php?title=Icecache_File_Format

I used the code from stackoverflow: Zlib compression Using Deflate and Inflate classes in Java

I throwed out the main method and added the code as a java file to processing (java dialect).

So i have

void setup() { 
  File compressed = new File(sketchPath+"/pc_oj_simple_AnimTake1_11.icecache");
  println(compressed.exists());

  try {
    ZlibCompression.decompressFile( compressed, new File(sketchPath+"/pc_oj_simple_AnimTake1_11.icecacheDecomp"));
  }
  catch (IOException e) {
    println(e);
  }
}

I get the following error: java.util.zip.ZipException: unknown compression method

here is the file: https://dl.dropboxusercontent.com/u/17630770/temp/pc_oj_simple_AnimTake1_11.icecache.zip

I aslo compressed a txt file and decompressed it again, this worked fine.

How can i continue to figure out what is wrong?

Community
  • 1
  • 1
clankill3r
  • 9,146
  • 20
  • 70
  • 126
  • What is the byte order of the computer architecture where the file you are trying to decompress was written and what is the byte order of the computer architecture where you are trying to run your program? – statueuphemism Jun 11 '13 at 20:31
  • the file comes from windows, probably 64bit but not sure. I try to decompress it on a mac 64 bit. – clankill3r Jun 11 '13 at 20:35
  • Sorry, I was asking for little-endian vs. big-endian information. It's likely to be an AMD or Intel chip in either of those machines with little-endian byte-order, so byte order is probably not your issue. – statueuphemism Jun 11 '13 at 20:45
  • Not sure if i follow you. – clankill3r Jun 11 '13 at 20:52
  • If the machine that wrote the file was a big-endian architecture and the machine you are reading it on is little-endian architecture, then you could have to swap the byte order in memory before you could do anything useful with it (depending on how the file format is defined). While I am not 100%, I would guess that this is probably not your issue. If your Mac is using a power PC chip, then that very well could be your issue. – statueuphemism Jun 11 '13 at 21:06
  • This has nothing to do with byte order. – Mark Adler Jun 11 '13 at 22:35
  • @Mark Could you have made that assertion with 100% certainty without requesting additional information? If so, could you tell me how you would know this? I truly am curious for my own future reference. – statueuphemism Jun 12 '13 at 00:01
  • 1
    Because zip, zlib, gzip, and all other standard compression libraries and utilities are written to be portable and entirely insensitive to the endianess of the host processor. – Mark Adler Jun 12 '13 at 02:11

1 Answers1

0

Though you said it was a zip file and you provided a link to a zip file, your data appears to not be a zip file. When I unzip what you provided, I get a gzip stream. Your code would decompress a zlib stream, which is a different format.

You should use GZIPInputStream to read the icecache file that is in the linked zip file. Or if using zlib directly, zlib's gz* functions.

Note that the reference for the icecache format is horribly confused on what format is what. It says "Each file is a zip archive", but goes on to say "utilizing the ZLIB library to save and load directly using a zip-stream". Wow, ok. So first, zlib does not produce or read zip files directly. zlib provides compression and decompression services for the deflate compressed data format that can be used by software that processes the zip file format. But zlib provides no code to process the zip file format (other than what is in the third-party contributions in the contrib/ directory of the source distribution). Along those lines, zlib has no such thing as a "zip-stream".

So what is it? Is the format really zip and you can't use zlib by itself? Or is the format something that zlib handles, and not zip? Fortunately this can be resolved with the example source code provided at the bottom, as well as linked below that in icecache.rar. That python source code uses gzip as the format that it is writing to. zlib does in fact support the gzip format (which is entirely different from the zip format).

This conclusion is further bolstered by the example file provided which, when unzipped, contains a gzip stream. That gzip stream when decompressed starts with "ICECACHE".

zlib's gz* functions should be used to read and write the gzip streams containing the documented icecache layout of data.

Mark Adler
  • 101,978
  • 13
  • 118
  • 158
  • Are you positive that what he wants is the ZipFile class? Are you positive that he didn't just zip the file up before putting it on dropbox? While compressing a compressed file can be rather redundant, he makes no reference to any file extension in the line `File compressed = new File(sketchPath+"/pc_oj_simple_AnimTake1_11.icecache");` – statueuphemism Jun 11 '13 at 23:57
  • You are correct. I looked at the unzipped file and it is itself a _gzip_ stream. – Mark Adler Jun 12 '13 at 02:13
  • The file extentsion is .icecache According to the official reference it should be zlib. The person who sended the file(s) zipped all of them together. So can it be that his zipping breaked the zlib? – clankill3r Jun 12 '13 at 10:55