I just spend about half a day searching the web and versiontracker for an appropriate database solution to start building a digital image collection which allows one to associate information at a greater level of detail with each image than iPhoto and a better way of querying this information to retrieve particular images. This is supposed to be a long-term solution, which basically should hold most of the digital images on my computer, research-related in the first place, but also personal photos meant for long-term storage.
I looked at Scribe, Filemaker itself, Devon Think and a couple of open-source solutions (none of which, however, appears to be developed systematically enough to trust one's data to it without having having programming skills oneself). In the end the conclusion I appear to arrive at, is that Bookends probably is the best suited solution.
- It allows for the level of detail I want to associate to each image
- It would allow automatic generation of captions to illustrations in articles through the combination of a citation and a custom format.
- It allows for quick visual browsing of the images by having the info drawer open in list view.
- It would allow me to leave the images themselves in one location on the hard disk, thus making it possible to reach out to them from various applications, saving Finder comments to the files to query this information through Spotlight and applications which rely on this, and entering keywords in Preview.
The possible drawbacks of using BE for this purpose appear to be:
- the necessity to create a record for each image at an individual basis.
- the lack of a possibility to import the metadata of an image file
In addition, there are two things I would like to clarify:
a) is it possible to insert attached images into a citation alongside the information contained in the database fields?
b) Suppose that in a dark future I will (have to) stop using BE - would there be a way of exporting the information contained in the database fields in association with the filenames of the files attached to the references in a format which could be imported into other database applications?
BE as a digital image repository
Re: BE as a digital image repository
Hi,gke wrote: a) is it possible to insert attached images into a citation alongside the information contained in the database fields?
b) Suppose that in a dark future I will (have to) stop using BE - would there be a way of exporting the information contained in the database fields in association with the filenames of the files attached to the references in a format which could be imported into other database applications?
a) Bookends won't include images in a bibliography. That's not really a function of reference management.
b) Yes, the XML exporter does that.
Jon
Sonny Software
Hi Jon,
Obviously including images into a bibliography or citations would not be a standard routine for reference management software, but would it be possible to tweak BE in some sort of way to achieve this?
Also, what about image file metadata - would there be a way for BE to "read" this when importing images for example?
Obviously including images into a bibliography or citations would not be a standard routine for reference management software, but would it be possible to tweak BE in some sort of way to achieve this?
Also, what about image file metadata - would there be a way for BE to "read" this when importing images for example?
Hi,
It's not a tweak, it's a major feature that I really don't think belongs in reference management software. FYI, you can drag and drop the image in the Info Drawer or Attachment Inspector into another application, like Word.
As for metadata, probably, but I'd only think that would be generally useful for pdfs (which contain references), but the metadata is rarely of any use in those cases.
Jon
Sonny Software
It's not a tweak, it's a major feature that I really don't think belongs in reference management software. FYI, you can drag and drop the image in the Info Drawer or Attachment Inspector into another application, like Word.
As for metadata, probably, but I'd only think that would be generally useful for pdfs (which contain references), but the metadata is rarely of any use in those cases.
Jon
Sonny Software
Hello Gijs,
There was a thread on the Devonthink forum a while ago about this, including software suggestions.
See:
http://www.devon-technologies.com/phpBB ... ght=photos
You might want to look at Aperture, which is of course pricey..
Best,
Gerben
There was a thread on the Devonthink forum a while ago about this, including software suggestions.
See:
http://www.devon-technologies.com/phpBB ... ght=photos
You might want to look at Aperture, which is of course pricey..
Best,
Gerben
Jon, dragging and dropping from the drawer would probably be exactly the sort of tweak I had in mind - together with the possibility to drag and drop hyperlinks to references this could be a pretty good way of managing illustrations to articles in a simple, straightforward manner.
As for the metadata - IPTC provides a way to embed captions, titles and keywords directly into the image file, which is of course very attractive in terms of the inseparability of these data from the physical file.
But never mind - I agree completely with you that BE should remain a reference management system in teh first place - there are enough applications out there which do a bit of everything but none of it satisafactorily. So, keep up the good work, I would say. Do consider the fact that I try to get BE to do what it is not designed for as a compliment to its power and versatility, rather than a critique of missing features!
Nonetheless, I think I am going to try how BE works as an image-management tool. In this case, would you recommend using a separate DB for it, or put the images alongside the other reference types in the main database? Keeping it all in one DB would probably have advantages in terms of being able to use the same keyword-lists so as to ensure consistency in assigning them. Or is there an easy way to share keyword-lists among BE databases?
As for the metadata - IPTC provides a way to embed captions, titles and keywords directly into the image file, which is of course very attractive in terms of the inseparability of these data from the physical file.
But never mind - I agree completely with you that BE should remain a reference management system in teh first place - there are enough applications out there which do a bit of everything but none of it satisafactorily. So, keep up the good work, I would say. Do consider the fact that I try to get BE to do what it is not designed for as a compliment to its power and versatility, rather than a critique of missing features!
Nonetheless, I think I am going to try how BE works as an image-management tool. In this case, would you recommend using a separate DB for it, or put the images alongside the other reference types in the main database? Keeping it all in one DB would probably have advantages in terms of being able to use the same keyword-lists so as to ensure consistency in assigning them. Or is there an easy way to share keyword-lists among BE databases?
Hi,
Keyword lists can't be shared because they are dynamic -- that is, they are composed from references already entered.
Having said that, you can copy the keyword list from one database and paste it into a keyword field in a dummy reference -- now you'll have all of those keywords in your database.
As for one db versus several, it depends on their purpose. If you might use the data from both in a scan of one document, I'd use one db. If you have dbs that are mutually exclusive, you can use several.
Also remember, though, that smart groups make it fairly easy to maintain several "virtual" databases in one physical file.
Jon
Sonny Software
Keyword lists can't be shared because they are dynamic -- that is, they are composed from references already entered.
Having said that, you can copy the keyword list from one database and paste it into a keyword field in a dummy reference -- now you'll have all of those keywords in your database.
As for one db versus several, it depends on their purpose. If you might use the data from both in a scan of one document, I'd use one db. If you have dbs that are mutually exclusive, you can use several.
Also remember, though, that smart groups make it fairly easy to maintain several "virtual" databases in one physical file.
Jon
Sonny Software