Retention of removed background BMP information in file

I’ve been making a number of files recently using background bmp to draw from (view>background bitmap>place). I’ve noticed that a number of these files have remained relatively large, even though I’ve then removed (as far as I know how!) the background bmp (view>background bmp>remove). When I’ve analysed the files (analyse>diagnostics>audit) it appears that the bmp is still in the file even though I’ve ‘removed’ it.

Knowing the size of the bmp I added and then looking at the overall resulting .3dm file size seems confirm this.

This was a relatively minor issue, until I accidentally added a 20MB jpg into one of my files, and now working on this file painful as it seem to pause with the spinning wheel regularly.

Attached is the full audit file from one of the affected files:

BryanH_3dm_audit.txt(9.6 KB)

Software information

Software versions
Rhinoceros version: 5.0 Wenatchee 2013-08-23 (476)
OS X version: Version 10.8.4 (Build 12E55)


Hardware information

Computer hardware
Hardware model: iMac13,2
Processor: Intel Core i5-3470S CPU @ 2.90GHz
Memory: 8 GB
Architecture: Intel 64 bit

Video hardware
Graphics: NVIDIA GeForce GTX 660M 512 MB
Screen size: 2560 x 1440
Displays: iMac

USB devices
Western Digital: Elements 10A2
Iomega: USB to ATA/ATAPI bridge
Apple Inc.: Apple Keyboard
3Dconnexion: SpaceNavigator
Apple Inc.: Bluetooth USB Host Controller
Apple Inc.: FaceTime HD Camera (Built-in)

Bluetooth devices
Apple: Apple Wireless Trackpad

OpenGL information

OpenGL software
OpenGL version: 2.1 NVIDIA-8.12.47 310.40.00.05f01
Render version: 2.1
Shading language: 1.20
Maximum texture size: 16384 x 16384
Z-buffer depth: 24 bits
Maximum viewport size: 16384 x 16384

Implementation settings
Use texture compression: No

Appearance settings
Antialiasing: 4x
Mip map filtering: None
Anisotropic filtering: None

Perhaps more practical for viewing purposes to attach the audit as a .txt file…

This sounds like it might be a Mac-specific bug, not sure though. In Windows there is a test command to get rid of this “goo” if it gets stuck in the file, it’s TestPurgeBitmapTable - I don’t know if this has been ported to the Mac, though.

One other way to “fix” this would be to unhide and unlock everything, select all (Cmd+A) then Export to a new file.


Fair one about the .txt file! I’ve noticed that some of the information I added has been stripped out as well so will do that next time…

Tried the TestPurgeBitmapTable but got the ‘not implemented’ warning as you expected. I also tried tools>file utilities>Purge Unused Information, which although removed dead layers etc didn’t seem to purge the bmp.

OK, I was afraid of that… Unless you have access to a Windows machine, I guess the only way out will be the Export procedure I mentioned above… You might upload the (unpurged) file to tech support for analysis…



Can you please add Background bitmap / picture option to Purge Unused Information. Now background bitmap will get removed when Material option is “yes”. What else “Material” means?

I noticed, it does not remove background bitmap if not used before command “TestPurgeBitmapTable” before going to “Tools” -> “File Utilies”…

I 2d scan alot. Then I’ll get the picture to Rhino by using command “BackgroundBitmap”. I use that command because there is option “1to1”. I’d like to use “PictureFrame”, but there is not “1to1” option. PictureFrame does not increase the file size so much. Is it possible to add “1to1” option to “PictureFrame”?


TestPurgeBitmapTable is implemented on the Mac. Because it is a test command you must type the entire command name perfectly.