Walter Roberson <email@example.com> wrote in message <firstname.lastname@example.org>... > Paul Skvorc wrote: > > > I have to deal with millions of individual files (images). I have been > > able to reduce the file sizes to something between 200 and 500 bytes. > > The minimum size that a file can have on my Dell Desktop using Windows 7 > > is 4k. I don't know if that's a Windows requirement, or from whence that > > 4k minimum derives. > > The NTFS cluster size is 4 Kb for filesystem sizes up to 16 Tb. That isn't > something you can change. > http://support.microsoft.com/kb/140365 > > > When paying for storage of millions of images, there is a GREAT deal of > > difference in cost between storing 4k per file and the 200-to-500 bytes > > per file of even the 8-bit-deep black-and-white files I currently have. > > By the same token, there is no value in spending energy on "getting to > > binary" if I am 'locked' to storage blocks of 4k. > > > Is there a method within MatLab to STORE images/matricies/files as true > > binary? > > What do you mean by "true binary" ? You can write whatever you want using fwrite() > > > Can that storage mechanisim overcome 4k minimum storage size that my OS > > seems to impose? > > Have you considered using zip or tar? > > http://www.mathworks.com/access/helpdesk/help/techdoc/ref/zip.html
It's not been my experience that zipping individual, small, black-and-white files results in any meaningful reduction in size. Furthermore, the time overhead of unzipping individual files would completely outwiegh what small gain might be realized in size. These comments of course assuming you're referring to ".zip" files. I don't know what "tar" is, but any "operation", like compression, is going to be time prohibitive for processing individual files.
> What do you mean by "true binary" ? You can write whatever you want using >fwrite()
I haven't experimented much with fwrite(). Do I understand you correctly that one can, using fwrite(): 1) Generate a file that is one bit deep, where: 2) A cell/pixel value is either "0" or "1", rather than 8 bits deep where "black" is 0 and "white" is 255, and in doing so, 3) "Save" seven bits of "space" for every cell/pixel, thereby, 5) Improving storage (not considering the 4k block floor) by 7 parts of 8? If so, that would be a "big deal" and I will have to invest some time to investigate and become more familiar with fwrite.