File size too big

I am running into the situation where any file that I save, even if it’s just one point object, has a minimum file size of 1.8Mb. I have been trying to figure out where this is coming from. I am starting with a default mm template, saving small, without plug-in data and without textures. Below is a sample:

OnePointCustomWS.3dm (1.8 MB)

I ran Audit3dmFile on the file and it appears the 1.8 Mb are coming from the “Properties” section:

Properties Section: 1898997 bytes (offset 441 to 1899438)

The above was created using Rhino 7.6 with my own personal scheme/custom workspace. I did the same from a Default scheme Rhino, same template, same conditions - the result is only 24Kb:

OnePointDefaultWS.3dm (24.0 KB)

Properties Section: 2744 bytes (offset 441 to 3185)

So, what the heck is ‘stuck’ in the properties section in the files that I create running Rhino with my custom workspace?? The workspace itself shouldn’t do that and there are no plug-ins that do not ship with Rhino that are currently active, no textures or anything else… :face_with_raised_eyebrow:

Hum… I need to step out, but I will poke at it - probably going over the same ground as you’ve checked but you never know…

-Pascal

A second set of eyes is always good! :smiley:

Is this Windows or Mac? The thumbnail image may be at play

Windoze…

I had a very similar situation in February. V7 File with no objects over 1 MB - Why?

1 Like

So it looks like the mystery hasn’t been solved… hmm.

On my end I am on the same computer, same Rhino version, same standard template file (mm small), same everything, except I am using different schemes to be able to start Rhino with different configurations - basically interface language and toolbar set. The one that starts with a basic default configuration with the default .rui makes small files, while the one with the custom .rui makes the ‘fat’ files.

Aside from the different toolbar set - which shouldn’t make any difference I think, what change from one scheme to the other might influence the thumbnail size or something else ? Very odd.

If you use Save As on your custom file, does the new file stay large? (It shrinks when I save it). Same in both configurations?

Can you share the .RUI?

Yes, it does, if I do that from my custom .rui scheme. However if I open the file created in the custom .rui scheme with Rhino using the default scheme and just re-save it, the file size goes back down to 24kb.

Sorry, but I cannot share the .rui here.

No problem. But the Save As shows that the problem is not intrinsic to the file, rather to the scheme, so the best way to identify the source of the problem (albeit tedious) will be to reset the .RUI changes piece by piece. I’d start with the language settings, because I can see some rationale for embedding info about that in the file.

No, it’s not the language settings, as I have schemes for English, French and German all using the default.rui, and they all are the same - small files.

I think I just figured it out though. In my custom scheme I have Options>Advanced>UseCompressionWhenSaving set to False.
I did this because having it set to True was making for very long file saving times with larger files.

In the default schemes it is set to True. That’s probably the culprit.

@davidcockey can you test?
@stevebaer - possible?

:crossed_fingers:

Yep, that’s almost certainly it, I turned off the file compression in the default scheme and resaved the small file that was 24kb - and it went back up to 2Mb. The question remains, what is it compressing that makes that much of a difference? I suspect it’s still the thumbnail.

Just tried turning off compression for a file of my own and it ballooned, the back small when I turned it back on. So repeatable.

Same repeatable behavior on both my laptop and my new desktop.

But what is the large chunk of data that can be compressed? When I previously looked at the saved, uncompressed file contents it appeared to be some sort of repeating “filler” data. A thumbnail can’t be over a megabyte; there are not enough pixels in a thumbnail.

They might be stored internally as higher-res images. A 960 x 640 uncompressed image at 24 bit color would be about 1.84 Mb…

I can repeat this and agree it is the uncompressed thumbnail causing bloat. We could add another option to differentiate on exactly what to compress if you think this is important.

Hi Steve,

I only noticed this because every time I uploaded a Rhino file here as an example, even the simplest one, it and took a second or two to upload, and the size showed 1.8 Mb, so I wondered why. Aside from that it doesn’t really bother me, but if for example you could compress only the thumbnails (even without an option to leave uncompressed) it might avoid this situation for people who have turned file compression off. I suspect nobody would notice. I only turned file compression off originally because I was saving some rather large files and they were taking very long to save.

Sounds legit to me. I added this to our bugtracker at
https://mcneel.myjetbrains.com/youtrack/issue/RH-64354

Thanks to this discussion for the first time I was made aware of the ability to disable file save compression via Advanced Options… after testing it a bit since we have been dealing with long Save times, I have to say that it makes a huge difference over here and seems too well hidden from the Rhino UI.

With compression, saving my test file on the server was 45s, no compression 15s.
On local drive compressed 10s, no compression 3s!
These are big time differences and while the file size goes up from 300 MB to 400MB, these days HD space is cheap and time is always expensive.

@stevebaer , @pascal - I would suggest to promote this switch to a more visible spot in the UI, like Options > Files panel, or even as a checkbox in the file save dialog (along with other options like save plugin data etc. - this would be a manual override of the global setting)

I am switching the compression OFF permanently…

–jarek