It is also perplexing because Adobe is gaining a great of experience in this field with the evolving multimedia database called Album. Sure Album now does not have some of the needed tools and it uses ACCESS as the db rather than perhaps a more robust option, but it has a very interesting metaphor which should be extensible to cover both professional and consumer needs for data storage, retrieval, editing, export, etc. BRIDGE could complement it or be a, uhh, bridge between the two. I personally was hoping to see some tighter connection between CS2 and Album this time around, but maybe something is there. My CS2 arrives Monday!
No, Bridge is not for archiving.
Bridge is designed to work with the files currently on your system. Yes, it would be nice to have more features in there – but this is just version 1.0!
BTW – designers and art directors DO want the stock photos.
Yes, it would be nice to have more features in there – but this is just version 1.0!
I like the sound of that! 🙂
While I like the sound of the "only version 1", do Bridge- and Album-indexed files take knowledge of one another at all? If an Album image is edited in CS2, does Album take advantage of the changes — or must one go through Album in order to make the edits — even though presently working in CS2/Bridge? Album-indexed images may have a rich enahncement of data, well beyond metadata, which could be extremely useful to users of CS2 (tags, collections, comments, accession dates, etc). On the other hand, Album has extremely limited and primitive file handling capabilities. CS2 is a number of steps ahead (although not exactly ‘robust’). I see synergies here.
On the other hand, Album has extremely limited and primitive file handling capabilities. CS2 is a number of steps ahead (although not exactly ‘robust’). I see synergies here.
I don’t. The two applications are aimed at entirely different audiences. Photoshop Album is an inexpensive consumer-orientated photo organizing product. An "electronic shoebox" for your photos. Considering that Album was more or less integrated into Photoshop Elements 3, there might not even be any future version of Album.
Photoshop is a much more expensive profesional image editing application. I don’t really see the two programs as a "system" designed to work together.
Hmm. I was thinking more of Bridge and Album having functions which would complement each other. Heaven forfend that I trade down from CS2 (arriving later today I hear) to Elements. Not going to happen. But, some functionality of Album could well fit in the Bridge construct (and vice versa). Album’s metaphor, for instance, can port to the professional data management arena.
Album itself is handy. I find myself the family touch point for five Albums of family photos which now have over 6,000 images going back to the late 1800s through yesterday. Being able to move tagged data and export easily in varying file formats is a good thing. It beats the daylights out of "shoe boxes".
My basic feeling is that corporately it is strange that the two from day one were not made to work better together. Just seems to be good sense. If one does not want/like Album, so be it. How many of CS’s functions do we personally NOT use?
Linus,
To follow on from Roberts comments. Bridge is a separate executable application so you can have it running without even launching Photoshop. Many of the Album storage and viewing features can be implemented using the Collections feature of Bridge. I suggest that you hold your comments on Bridge until you’ve actually experienced what it can and can’t do.
Photoshop is a much more expensive profesional image editing application. I don’t really see the two programs as a "system" designed to work together.
It doesn’t have to be a system. The introduction of a data base and a hierarchical keyword structure in Bridge would do it.
Yes indeed.
If Album had a more robust & extensible db and if Bridge had one at all, then much more would be possible. I’m still awaiting my CS2 but would appreciate clues from those more fortunate as to ways of leveraging Bridge and Album.
This thread should not be read stretched to mean that cross functionality is essential to me. The possible lack of it, given early first responses however, is intellectually curious to me. As well, the functionality would be helpful to me. And others I suspect.
What features are in Album that you believe we should have in Bridge?
What is it you can do in Album that you believe not to be possible in Bridge?
This thread started as a query about Bridge capabilities. Given that, and given that my copy of CS2 (I use 7.0.1 now) has not yet arrived, may I speculate on what I would like to see in the future?
The answer is a database.
The "Bridge Database" would then have a number of charateristics, very much like Album including the ability to store, find and retrieve multiple versions of images across any number of media, with locations not only assigned within the program but also through the MS Move command. (Cut & Paste would be great but not essential.) It should also automatically accession images added from wherever to named folders/directories — and not to other named or unnamed folders/directories.
Extensive metadata should be retained and should be searchable with full Boolean terms.
Location data types (GPS-derived or derived from other sources) for an extensive list of projected and non-projected, metric & latitude/longitude, coordinates. (GPS is a datatype listed for Bridge, but there is no spatially-enabled viewer in Bridge. That should definitely change; we should all be able to FIND by spatial means and DISPLAY by spatial means.)
Collections should have many new characteristics and should allow for image name & sequence changes on the fly.
Tagging to a number of levels, 5, 6 who knows? Tagging should also allow for inheritance. (If there is a tag for "WEDDINGS" and under it tags for the names of the couples, moving the names sub-tag or sub-category should drag with it the "WEDDINGS" category so one does not have to drag twice. (The db should also keep track of the people separately because they will show up under GRADUATIONS, PORTRAITS, etc.
The db should provide consistent service to all images introduced to any of the Adobe products. Hence directly finding and editing in CS2 an image introduced in Album should be seamless to a user in either application — or to a user of Illustrator, etc., etc.
Now that you’ve taken the time to explain what you want, can I have your permission to relocate it to the Feature Request sub forum?
The reason I ask is that it’s more likely to be reviewed and noted by Engneering when placed there than it would be if left here to drift into the archive.
Absolutely. By the way, you might want to add a fulsome SQL capability so that it is mightily customizable. Thanks. Oh, I got my CS2 20 minutes ago.
By the way, you might want to add a fulsome SQL capability so that it is mightily customizable
<drool> yes please. 🙂
Ah but ah!
All the features previously and elegantly posited if I may say so have a major (IMHO) limitation: image files.
These features (IMHO) are operating system features or at least should be.
Basically, unless I am making some profound errors, these describe a present and past files feature. For example: work in progress, archived work, active work, …
This is not to denegrate the features at all. They are fantastic!
But what about nested metadata?
Designers use their own metadata, sales-order-processing insist that the designers metadata is removed and replaced with a unique, distinct and eminently trackable SOP string and, of course, PR insist that the previous 2 sets of metadata (now password protected and competing in keyword string) be removed forthwith and replaced as people out there should not have a notion of how intrinsic SOP works and besides it has a jolly good PR aspect that will tie in with corporate identity issues.
Accounts disagree (SOP reference) Design team disagree (well it’s not creative is it?)
So, I guess, nested metadata may be important in images and in any file?
