Saturday, March 20, 2010
Time isn't free
Slice and Dice takes up a lot of disk space because it creates and operates on bitmap images, each one of which takes up 22 megabytes, and keeps half a dozen for each slice of a print. That eats up the gigabytes in a hurry.
The problem is that if you have a nasty STL that you've pulled out of Thingiverse, for example, you have to repair the faulted slices. On the recent torso that I printed about 6-7% of the slices were faulted. This usually meant dotting in one or at most two bits on an image to put things right. The problem is that after you've done that on 30-40 slices you're rather hesitant to throw all that work away because you need the space.
Some weeks ago, I discovered that if you zipped bitmaps you could reduce their size by about 95%. This morning I looked into converting over the storage modules to do this using a compression/decompression api. I quickly realised that this kind of job was going to require 3-4 man-days to do. Instead, I went down and bought a two terabyte external disk.
Subscribe to:
Post Comments (Atom)
9 comments:
Hi Forrest,
Just wanted to let you know about http://www.icsharpcode.net/OpenSource/SharpZipLib/ in case you didn't already. I don't know if you meant adapting this or something else. I believe you can use it directly from vb.net just by adding a reference to it.
I have enjoyed your posts for a long time now.
Thanks,
Bart
its kinda funny how that works eh. i have been there too.
LOL! Yes time is valuable; but creative time is priceless. I was eyeing 2tb drives at fry’s recently just for disk to disk backup.
Bart: Thanks for the link. I know if I ever get this code in shape enough to really distribute it that I'll want to do image compression, so that isn't really off the table in the longer run.
Freds: Yeah, I got a Seagate. It is amazing how hard disk price/byte has dropped over the years. Back in 1981, I got a 5 mbyte hard drive for a little 8 bit multiuser computing system. It cost $5,000. I paid about $100/terabyte for this one. :-)
Hey Forest,
This is a silly quesiton that you've probably already thought about, but are the images stored as 24-bit BMPs? You might be able to reduce the size to 1/24th (if you're not colour coding things) by using 1-bit bitmaps?
Peter: It's not a silly question, but I am colour coding things. :-)
Hi Forrest,
Have you looked at saving a .gif instead of .bmp files? .Net seems to handle both, it might just need changing a flag somewhere.
(http://msdn.microsoft.com/en-us/library/47591zc7.aspx). gif files will save you megabytes.
Also, given how you're editing a number of graphics files (if you're doing this a lot), something like Gimp with the GAP (gimp animation plugin) will allow you to load each file one-after-the other, so might be easier for multiple editing.
:-)
Renoir: I'll check those out. I didn't know that .NET Image supported GIF. Mind, I have the disk space for the moment, so I'm not particularly worried about saving disk space.
Gimp looks like fun. :-)
.Net will happily support GIF and PNG images... the latter would be useful if you are using (or intending to use) more than 8 bits of colour coding information, which is the max you can fit in a GIF file.
It might also matter than the .net System.Drawing stuff does not play nicely with 8bit image formats... you can't create Graphics objects from them, for example. Depending on what you do in your UI, this might make using GIFs impossible.
Post a Comment