Hello! Newbie here. I had assumed because of the images like maps and real estate pictured in the introductory demo materials that images could be stored directly in Panorama X. I tried finding something in Help and online documentation. Then I started reading forum posts. I understand why the size of image (or other potentially large files) could be a disadvantage for keeping everything in memory. This and related topics are covered in many posts. Particularly of interest are those related to photo databases.
To advocate for the option to store images in relatively small databases that don’t consume much memory anyway I will give an example. My team needs to filter over 1200 applicants for 6 positions. Each application PDF is over 40 pages (those can be stored separately). Yet I need a visual clue (JPG or PNG photo extracted each PDF) to remind who was interviewed along with the other fields characterizing each applicant. These are currently saved in an Excel spreadsheet. However, we know from hard experience that the “rows” of excel spreadsheets are not cohesive records. One bad sort without the whole spreadsheet being selected and the whole spreadsheet is corrupted. I hoped to store and manage all this data in Panorama X both for the robustness of a database and the robust undo when I make an error. Linking to external image files will not work because both the database and the images get moved around in the course of data reorganizations.
Alternatively, if anyone can suggest a modestly priced Mac database that could import Excel or Numbers, incorporate images, and offer reliable maintenance of all the cells linked in a record, I would like to hear about your suggestions.
As a related separate issue, there is no way that I have found to import the spreadsheet directly. Excel does not have an adequate export to JSON. A CSV export of the spreadsheet deletes the images. There are too many to manage this manually per image.
Checkout the filebookmark function under help. PanX’s attempt to solve your moving image target problem. You still can’t display those images in the data sheet but you could in forms of various sorts which might well serve your purpose. Excel files can’t be imported in their native format. But if you can get excel to export what you want, how you want it, as a comma or tab separated text file PanX can probably import it. The hard part isn’t getting that into PanX, it’s getting it out of Excel the way you want it.
I would suggest creating a folder for the images in the same folder as the database, and then in the database specifying the images using a relative file path. Then you can move the database anywhere you want (even another computer), as long as you make sure to also move the image folder.
Note: I don’t think @JohnB’s suggestion of filebookmarks is needed here - it would be much simpler to keep all of the images together in a folder right next to the database.
I’m not an Excel expert, or even a novice really. It sounds like you are saying that you have embedded the images into the spreadsheet document itself. I wasn’t aware that that was possible.
I think you’ve identified another good reason NOT to embed images into a database. Once you’ve done that, the images are now locked away in a proprietary format where they can’t be accessed by any other program. Of course the images aren’t included in a CSV export, there is no way to represent an image in CSV format. I suppose it theoretically could be possible to export images to JSON by including gigantic binary blobs, but that would be very awkward and non-standard and I’m not surprised that Microsoft doesn’t do that. As I mentioned I’m not an Excel expert, but it would not surprise me at all if there was no way to get images out of an Excel document.
Since Panorama keeps the images separately, there’s no problem later if you want to use the images in some other program.
By the way, for many years Panorama did allow images to be directly stored in the database in RAM. This feature was virtually never used, so we removed it from Panorama X. We didn’t get a complaint from a single customer about this feature being removed.
Storing the images in a folder is the simple solution, but @mpoler had suggested that might not do well with his overall workflow. And that he was concerned with PanX’s limits. So I want him to know about the relatively new file-bookmark feature embedded with PanX’s large feature set existed, to make more complex solutions possible.
Let’s look at another more involved alternative. This involves adding an Image folder to the database package itself and then populating that folder with all the image files you need for your database. This could create a rather large file but the images in the folder will not be loaded en masse in memory when the file is opened. It is just a storage folder that will travel along with the database if it is moved.
The first step is to create the Images folder within the database file package. Here is some code that will create the Images folder inside the package and then open a Finder window to that location ready for you to populate with all your images.
save
makefolder posixpath(dbpath()+info("databasefilename"))+{/Images}
shellscript {open -R }+posixpath(dbpath()+info("databasefilename"))+{/Images}
save
Note the save command at the beginning which will save the current state of the database before adding the new folder and then again at the end just to be sure. This is needed if you have AutoSave active as it will complain when triggered that you have altered the file with another application. If you press the Revert button you should be fine and the new Image folder will remain in the package. It would be best to trigger the AutoSave by choosing Save from the File menu before doing any other work with the database file to make sure your work is not removed with the Revert button.
Ok, now that you have all the images in the new folder named as you want them, you can add a new field to the database possibly called Images. This field will be populated with image file name corresponding to the individual person’s record. Below is a simple file I made to show how this might work. I have a field with names and another field with the image file names. I also created a new form with an Image Display Object with this formula in the Formula pane of the Properties panel:
I bet it’s possible to have a New or “+” procedure where you drag a photo to a target area on your form and that image is copied to the image folder, its path is stored as a record, and the image is displayed. I don’t know if it would be better/possible to copy the file from wherever it is to the image folder or move it to the image folder.
If you’ve given yourself an “Add” ability, it would be good to have a matching “Delete” ability where dragging a photo to a trash-type graphic would remove the photo and record link - with the appropriate warnings before the action. Or, as a safety measure, you could just remove the link record but keep the photo - maybe by changing the file’s name so you can identify (and sort out) who/what the photo is and its non-linked status.
Interesting perspectives and implementation ideas. Thank you all for impressively detailed responses. Good ideas. I’ll experiment to see whether I can come up with a functional solution superior to the current Excel spreadsheet, taking advantage of features of Panorama X. Thanks for the boost.
This is an appealing idea that I looked into building into Panorama at one point a few years ago. If it works, great, but based on Apples documentation of how NSDocument handles file packages, it shouldn’t work. Basically, according to the documentation anything extra inside the package could/should be deleted whenever the file is saved. I think someone (probably Gary?) tried this and said that it did work, but I personally would not risk it with my images. (Hmm, I guess Gary is saying in his post today that it works.) Although putting the folder of images “next to” the database is not quite as “clean” a solution as putting it inside the package, I think it is safer. Even if it does works now, there’s no telling if a future version of macOS might break this, and in a catastrophic way (all images lost). So before anyone relies on this, I want to make it clear that putting the images inside the Panorama package is an experimental technique that falls outside of Apple approved techniques.
Gee, I guess I’m alone in missing it, so I’ll have to speak up: Around 2008-9 I needed to catalog a substantial coin collection. I was able to:
Photograph both sides of hundreds of coins
Process them in Lightroom
Use Lightroom’s formulaic naming tools to give the exported jpg files meaningful names
Drag and drop 100’s of jpg files onto a Panorama field and instantly have a database with 100’s of records.
Because coins need two images per record, not just one, I used Panorama’s text formulas to rework the original image’s address to look up the corresponding reverse side image to populate that field in each record.
That all worked great and was one of the coolest things I’ve ever done with Panorama. Sorry to hear it’s now a lost feature.
I do not have an image file with a picture of your avatar, so that database actually contains the picture itself, instead of a couple dozen bytes or so of text needed to specify the path to an image file.
Panorama 6 had two methods for displaying images. The method you are describing is still available, and still cool. It sounds like you never moved that particular database over from Panorama 6 to Panorama X, but if you did, it would work, possibly without modification.
The other method was so obscure that most users weren’t even aware it was available, and didn’t notice that it was dropped. In fact, as I said, I don’t think anyone has noticed, and that is still the case unless someone else speaks up. As Dave mentioned, this method involved setting the field data type to Picture. That data type is no longer available.
Well, my ears are burning… I used to use this a lot, to store images of molecules in collections that could be used for designing reaction schemes, etc. What was great about the old version is that the image could be copied from my drawing program (ChemDraw) and pasted in as a pict format that allowed the image to be retrieved by copy, pasted back into a fresh ChemDraw doc and edited. ChemDraw stored the vector directions in some hidden section of the pict format allowing this. That’s not possible with a jpeg or pdf, etc, which I use now to work around the loss of the picture field.
I have a feeling that all of this would be gone now anyway, as I think Apple has moved away from the pict format, and it was always awkward for the ChemDraw people to maintain this editability. I surely missed the function, but I’ve moved on. Textlist alone makes up for the loss, not to mention all the other advances in going to X.
Being more than 10 years ago that I did it, it’s hard to remember what exactly I did do. Trying to open it today in Panorama 6, it looks broken, but the field isn’t a Picture data type, and it seems to be a file path name to where the jpg is on disk in a folder with the database, but the path name is absolute with a root directory that’s obviously a previous machine. It probably would still work with corrected path name or better yet a relative path name instead of absolute.
Yes, in fact Apple moved away from the PICT format over 20 years ago, OS X never supported it well. It was format you could do some cool stuff with though, like what you are describing with ChemDraw.
A recent addition to Panorama X is the clipboardimagesave statement. This allows Panorama to take an image from the clipboard and save it as a file so it can be saved, removing the intermediate step of you having to create the image file yourself. I use this for copying illustrations created in Keynote into the Panorama documentation. In Keynote I select the elements I want and copy them, then go to Panorama and press a button to insert that into the documentation at the current point. The procedure converts the image to a file with a unique name, then inserts that name into the database.
In theory, pdf is a wrapper that can contain raster and/or vector graphics, so it’s possible to have editable vectored graphics inside. Illustrator can open and edit those graphics as well as my 2D CAD program, PowerCADD, but a) it’s a GIGO thing and the creator had to put vectored graphics in in order for you to get it out, and b) the vectored graphics is all based on Postscript.
