PLEASE make PictureFrame > EmbedBitmap=Yes the default ! I know it is supposed to be sticky once it’s set, but on every new install it is set to No. There is no reason in this day and age not to store the image in the file. If the user is really worried about file size then they can go in and set it to No.
It’s really easy to overlook this option due to the order of things - first, you choose the bitmap in the file dialog, then immediately you get the screen pick prompts to set the image - it’s easy to miss the command line options, and once you have terminated the setting the image, well, all the options are gone… You have no idea if the image is embedded or not.
As a corollary - I would like a somewhat more obvious way of post-saving a non-embedded bitmap in a file. Going into Doc Properties > Rendering and checking “Save support files in 3dm file” is not that obvious (to me at least); also the trick of re-doing the picture frame operation (with embed=yes), saving the file, then undoing the import is also not that obvious… How about EmbedPictureFrameImage…?
Hi Mitch- thanks, I’ll see what we can do. I’d also add my own wish- the ability to selectively purge embedded images. Currently, embedded images are permanent which is not good, in my opinion- I’ve seen cases where files are copied as the basis for other files- like a template, and the bitmaps accumulate making for some mysteriously large files.
For sure… Somehow this should also be semi-automatic, if a picture frame is deleted and the file is saved and closed, than the image should be purged. I guess it needs to be held “in storage” for undo purposes, but once the file is closed (or you hit ClearUndo), it should go…
Hi Mitch, all - in V6, Picture(frame) images are handled the same way as any bitmap used for a texture on a material and not embedded in the bitmap table.
it would be very crucial, that on DWG-export all images are properly (for the DWG-format) embedded into the drawing.
Many folks out there have to derive and deliver DWG-files from their Rhino-Work-Files.
Sadly I have to say the DWG-format it not going to fade in the near future.
Almost every big company uses DWG as reference-files. And even worse is the fact, that you have to
always stay compatible with very ancient versions of DWG, since internationally you have to assume, that
companies you would work together with in i.e. Bolivia or you name it, don’t usually work with brand-new versions
of any software.
Through the last three years I worked out a workflow, that allows for the rel. quick export of DWG-files from rhino with embedded jpg-images. This is very handy, when it comes to drawing i.e. mannequins or the like or in the case, that you would like to get assembly instructions or this kind of more graphically oriented documentation out. To be able to embed images is very important in these
workflows. And people on the other side don’t like externally referenced image-files. Neither comes it in handy, when you have set up a directory on a server, to which you upload your finished drawings, nor when you have to mail these data into other countries. It’s a pity and a fact as well, but external references of any kind are the most common reason for madness and confusion in our world.
I really beg for the options that Helvetosaur and others asked for. You can be sure to make many people happy with them.
I’ve been evaluating R6 for the last few days and find myself getting bogged down with worries about making any changes to my R5 files that will make them unreadable by a colleague who still uses R5.
Much to my surprise, one of the more trivial issues I’ve discovered is that a ‘PictureFrame’ image (R5) wasn’t visible on my new laptop (R6) because the image was never embedded in the Rhino file and folder paths are different. (my colleague never mentioned that he couldn’t see that hidden image/layer either)
So I’ve spent time testing ‘PictureFrame’ and ‘Picture’ embedding and somehow I ended up with a folder called ‘/test_v6_embedded_files’ associated with a new file I created in R6 (test_v6.3dm)!? I can’t repeat the sequence of events that created it… Other experiments seem to embed the image within the .3dm file without any associated folder.
What happened? This is just one of several puzzling surprises about R6 that I fear are only the tip of the iceberg. I have hundreds of “old” Rhinno files, so moving to R6 has me feeling dis-empowered and vulnerable…
Hello - Pictures in Rhino 6 use the images as textures like any other material (there is a special Picture material type) and if Rhino is set to save textures with the file, these will be saved - they are never embedded into the bitmap table as they are (optionally) in V5. The folder you see holds the images on disk so they can be seen and used by the materials.
But - is there something that is not working for you now, or is it you are concerned that it might not work?
Well, for me this is a case of “If it ain’t broke, let’s fix it anyway”…
IMO, picture (frame) objects are not the same as textures applied for rendering - while technically they might be alike, they are generally used for different purposes. Picture (frames) are often used as visual reference objects for construction and thus it is very important to keep them in the file (automatically) as long as they are needed. That is why I have argued in the past that the default would be that they are always saved with the file. That was not the case with V5, and is still not the case with V6, as saving of textures with the file is also not enabled by default.
So now, we have to remember to save the textures with the file, and on top of that, every time you transfer the file somewhere else and open it, it re-creates the “embedded files” folder there. So it means your directories get “littered” with these folders that you have to clean up afterwards.
It’s now more “broke” than it was before, in my opinion…
Yep, but in that case, if you send the file somewhere where the original textures are not present, Rhino will automatically create that “Embedded files” folder with the picture image in it.
Hi Mitch - yes, correct… is that bad? What was broken is that embedded pictures could not be removed, and not embedded ones could not be embedded. There were test commands to partly work around these but it was in fact broken (massive file bloat). I agree that it would be better to special-case Pictures for saving or not, but I’m not sure what is so bad here… ?
Yep, for me that’s what’s broken - I’ve never considered picture objects to be just ordinary textures and most often are used as reference images. When you send them to someone and the textures weren’t saved, they have nada. If the textures were saved, the picture image is there, but you get the annoying embedded files folder wherever you happened to store the file. If you delete that folder, every time you open the file it comes back.
Actually I like the separate folder for the embedded pictures. Most often I use pictures as reference images while modeling, and don’t really need them included in the file when I’m done But having them available in the adjacent file is handy rather than having to navigate back to the original source file. If I want to send someone the 3dm file with the images included it’s not hard to tick the box to save textures
