Embed PictureFrame image

Rhino Rhino for Windows
#21

Yes that’s true.There are still 2 reasons I prefer the current system.

  1. When I work with multiple bitmap images in creating a model, the size of the file gets much larger, storing information I really don’t actively use even if I may want it for reference. For example in recreating vintage instruments I often work with multiple photos and PDF scans of hand drawings to get a full overview of the project.
  2. When I export the file for manufacturing I don’t want to have to worry about inadvertently sending lots of source data that the workshop will find confusing.

While this works well for me, I do agree you should have the option to save the images in the file without creating a secondary storage file, and without having to resort to embedding them as textures, which hardly seems intuitive. It seems like the developer took advantage of the mechanics of the system without really considering the workflow of their customer.

#22

Yeah, pic folders are an annoyance. :slightly_frowning_face:

#23

When doing concepts I work over drawings and site diagrams all the time using the Picture command, and they never transfer reliably to my colleagues reliably. It worked intermittently for a time, I wish I could figure out what is happening.
I always send with textures checked “on” when exporting to Rhino5 (they are on V5 Mac, I use Win10 V6). I wonder if there is a functional difference between “Save As” and “Export” when it comes to embedding files for export in a Rhino5 file. Can this be true?

#24

Hi, V5
If my images had been embedded, I have currently 63 images, jpg, 46.6Mb total size, all linked and adding more, for the project, so if they had been embedded by defaukt, would this cause it to run slow, as currently it takes 25 secs for a copy paste of e.g. a curve from it to appear in an new file, and save takes 20 secs. due to arrays of bolts with spirals, holes and so on. ( quicker now I have deleted out al thread realistic bolts).
I do so many PictureFrames, would embedded cause problems ?
If its easy to choose embedded = no then its just as easy for folk to select embedded = yes.

I know I would forget to do so and perhaps then cause speed problems.

Steve

#25

Yep, that could be a symptom…

That’s probably normal with a file of a certain size, depends on how fast your hard disk is.

The choice of embedded or not is up to you. If the images are not embedded, if you open the file somewhere else other than your computer where the images are stored externally (referenced), they won’t be there. On the other hand the file size will be a lot smaller, and perhaps the save times faster.

You can try it out yourself, SaveAs a copy of the file under a different name, and make sure you clear the checkboxes “Save textures” and “Save plug-in data” before hitting the save button. See if the file size gets significantly smaller. Then try copying a curve out of that file and pasting it into another and see if it goes faster.

1 Like
#26

Will do,
I see , having just embedded an image into a post, the next pictureFrame is also embedded =yes.

I never look at the options as it does what I need without doing so.

So it holds the embedded option used.
When I have 5 mins, not anytime soon I will test to see if that remains so after a new file is created and after reopening that existing file. Sounds like No is what to expect for a new file, that suits me.
If I found they were embedded, then having to go through and reinsert files, scale them to where I had them etc etc, that would be impossible., the stuff nightmares are made of.
Having to remember to not embed when doing new files, just one more thing waiting to catch you out and cause mayhem further down the line. Perhaps have the option to decide at install and its saved in the prog thereafter.

Steve

#27

Just not sure you don’t have it backwards - if the images are not embedded - that means they are not stored in the file - and you move the file elsewhere, you won’t have them…

#28

I have stumbled accross this issue and I must say it is annoying and unprofessional sending file and folder with embedded image to the client, otherwise there is no guarantee the image will be there.

#29

If the “Save textures” box is checked, Rhino should store the images in the file. On the destination computer, the embedded files folder will be automatically recreated in that case, it doesn’t need to be sent with the Rhino file.

1 Like
#30

OK, thanks.
I will spread this info in my team.

#31

I observed that also.

Regards
Rodolfo Santos

#32

Being prompted with the “save support files” dialog, I didn’t expect it would lead me down this Rabbit hole. Shouldn’t external images (pictureframe) be treated like blocks with the option to link or embed? That also makes for an easier time seeing which images are saved within the file or external links. Why not stick to industry conventions here? Photoshop, Illustrator, Autocad, 3ds Max and Revit all do more or less the same thing with a linked files window/ panel. For textures in the traditional sense, it can stay the way it is.

E: What I mean to say is there would not be a discussion on this if linking/ embedding pictureframe files were handled through such a dialog (also for relinking).

1 Like