Estimating image size in new format?

[jawzx]

Hi! i have a large-ish image archive (many terabytes) that is currently in TIF format, I've just recently gone though it and made sure everything is LZW compressed, which saved several terabytes, but I'm wondering if there is a way to estimate the image size when changed to a new format -eg: converting the entire archive to PNG.

I want to get a rough idea of how much storage I am likely to save without going through the entire process of ACTUALLY converting images. It took several weeks of off-peak CPU time to get everything LZW compressed, and I was checking with

Code: Select all

identify -ping -format %C

to make sure I wasn't duplicating effort... Is there such an estimate feature somewhere in convert or mogrify? I can't seem to find one... Or does anyone know of a method to perform such an estimate... I certainly don't need to estimate it for the ENTIRE archive, but there is fairly wide image variation and a largeish sample set will be required to get a good idea of savings...

If the archive changes from TIF to PNG some of the processes that interact with it will need to be adjusted accordingly and I don't want to just jump in and start changing image format without having a good idea weather the disk usage savings are worth the effort.

thanks!

[snibgo]

For my photos, I find that TIFF ZIP is about 24% smaller than TIFF LZW. PNG (with no compression specified) is about 3% smaller still, but takes longer to process. Your mileage may vary, of course.

Are your images 16 bits/channel/pixel, or something else?

EDIT: Sorry, I didn't answer the direct question: "Is there such an estimate feature somewhere in convert or mogrify?" No, there isn't.

[jawzx]

It's a very diverse archive, there are 1 bit, 8 bit, and 16bpp images in the archive. I suspect the 1-bit images are about as small as thier going to get already in TIFF LZW, 27% disk savings on the other images is not insignifficant when we're looking at over 5 million images, but then again disk space is cheap these days...

[snibgo]

And will keep getting cheaper, as far as I can see. We all remember the days when a terabyte would cost a million, plus the cost of the large building to house them, plus a huge electricity bill. Currently it's less than one day's wages.

A couple of experiments: for 8 bits/channel/pixel, the savings of PNG over ZIP, and ZIP over LZW, seem about the same as my post above. For 1 bit, PNG is slightly worse than ZIP.

[jawzx]

Indeed, I remember when we first broke a terabyte... we had a really compact system that only required two full racks to do it! These days my paltry 20 terabytes is one small corner of our aggregate server storage (over 2 petabytes at last count, most of it flash...)... It's big enough for IT to make me keep a reign on it, but in the grand scheme it's pretty insignificant.

y'know I've never used ZIP compressed TIFs... I think there must have been limited support or something back in the days... Or maybe LZW's lossless-ness and quick processing where what got me stuck on it years ago before I had a load-scaling virtual machine with up to 64CPUs to throw at my image-batching needs