Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3

Deprecated: preg_replace(): The /e modifier is deprecated, use preg_replace_callback instead in /home/content/60/9972860/html/smf/Sources/Load.php(225) : runtime-created function on line 3
Latest posts of: agillanders
The DAM Forum
Welcome, Guest. Please login or register.
October 28, 2020, 10:49:38 AM

Login with username, password and session length
Search:     Advanced search
28033 Posts in 5147 Topics by 2903 Members
Latest Member: kbroch
* Home Help Search Login Register
  Show Posts
Pages: [1] 2 3
1  General / General Discussion / Re: Is the DAM Forum dead? on: June 13, 2013, 09:24:25 PM
I also have concerns about the shift to LR. I don't like it's workflow for my finme art work (I do a lot one image at a time - the bulk handling stuff in LR is mostly a waste of time for me). I quite like LR for its catalog but that's about it - my ingestion / processing is centered around ACR / Bridge / PhotoShop and I archive derivatives later. I too have gone the DNG route although being a natural born pessimist I have kept all the NEF's on a backup drive too. I just haven't had to touch them in a long time but disk space is pretty cheap these days.

2  General / General Discussion / IPTC-PLUS for licensing on: April 28, 2011, 06:41:47 AM
I am interested in tightening up the language and terms of licenses I provide and also in helping my photo club to choose a direction and to help its members be more effective in their licensing. I note with interest a number of significant players (not least of which is the IPTC themselves) supporting the PLUS (Picture Licensing Universal System). See for more details including a free Toolkit providing a plug-in licensing panel that extends the IPTC Core panels in CS3/CS4 to match the upgraded panels in CS5.

Is anyone actively using the IPTC-PLUS universal licensing format and if so please will you share some thoughts on how you find it for yourself, how do your customers react? Also how do you apply it - with the CS panels or some other way?

Finally does anyone know of example code or a component that would allow a .Net website to "brand" an image with a license string, or the extended metadata, on behalf of site members.


Alistair Gillanders

3  DAM Stuff / Keywords and Controlled Vocabulary / Re: Defining Photographic Genre on: April 21, 2011, 11:18:30 PM

Just thought I'd post an update 10 months on...this has worked remarkably well. One of the critical paths to success was to accept that a given image can fit more than one genre. I am looking to characterize the image not fit it into one and only one box. So far many images can be acceptably fit into one genre, two covers the vast majority...I think there are a very few with three but that is as likely to be the photographer being lazy as it is a true characterization of the image.:-)

By implementing this in a database as a bitflag field it is trivial to characterize images under one or many genres with a single value and hence do powerful searching and filtering in SQL. I've also used it to characterize club member's interests and can match member's with similar interests as well as images that are relevant to them.

It is amazing what a controlled vocabulary will do for you when you get ruthless about scope creep!

4  DAM Stuff / Keywords and Controlled Vocabulary / Defining Photographic Genre on: July 19, 2010, 08:16:39 AM
Hi folks,

I know this is a challenging one and it can cause heated debate...I am looking to define a set of 'genre' that allow a grouping of images by something that might generically be called a genre. Having done quite a bit of research one of the best raw lists I found was at one of the Pentax forums (

However this still mixes function and subject and is a very long list where a good number of the supposed genres can be considered sub-topics of a broader genre. So I have tried to organize all this and I am need of feedback regarding the results. My intended use is twofold: I am developing software for a large photo club and the international PSA recognized event they organize each year; and I tag many of my own image library with hierarchical keywords starting with genre. My objective was to try and group, and regroup, and force fit within reason into a list of 10 or less overall genre...I finished with 9. What do all you CV folks think?

Close-up (includes macro, scientific, forensic, astrophotography, photomicroscopy etc)
Creative (includes abstract and alteredreality)
Event (includes sports and wedding)
Model (includes glamour, fashion, boudoir, nude)
Nature (includes wildlife and landscape [no hand of man])
Photojournalism (includes documentary and human interest)
Portrait (includes candid, studio and environmental)
Still Life (includes studio and product)
Travel (includes transport, landscape [pictorial], cityscape, urban, architecture, aerial)

This deliberately excludes what I consider to be more a function than a genre. For example commercial, advertising, stock, fine art etc are more about the designation of usage rather than content. A shot of a given genre could be used in all the functions depending on the job. One of the biggest confusions I found was this blurring of form and function.

Thoughts, corrections, general abuse...all welcome!:-)

Regards, Alistair
5  DAM Stuff / Naming Issues / Re: Folder Names - spaces or not? on: January 11, 2010, 03:16:48 PM
Hmmm...naah...not buying it.

It would take seconds to use a decent bulk renaming tool to replace the spaces with underscores if the highly unlikely scenario you describe were to come to pass. In general OS capabilities improve, they don't regress, and spaces in both folder and filenames are here to stay in most mainstream platforms today. And quality software manages that since it is part of the OS capability. You could never get MS Logo certification without such basic support for example.

So my current platform makes it easy to do.
Future platforms are highly unlikely to regress.
And I already have the tools for a trivial fix if it really did become an issue.

This is one of those areas that I think people look for problems where really they are minimal to imagined at worst. The readability enhancements improve my workflow every day. Not to do that guarding against a future "will probably never happen" scenaro that is easily dealt with is just clinging to sacred cows. Go forth and enjoy the space say I, freedom can be yours too!:-)



PS: And yet I still won't use spaces in filenames myself...what is this disease we have?
6  DAM Stuff / Naming Issues / Re: Folder Names - spaces or not? on: January 10, 2010, 10:12:08 AM
Hi there,

We're talking about FOLDER names not FILE names. I agree 100% with you regarding file names because they will often be visible on external systems in one way or another. However the folder names on my own archive platform are never seen anywhere other than my own platform. And if I am comfortable that my platform handles spaces OK then there is no problem.

FWIW I have no been operating for a few months with spaces in some of my archive FOLDER names and it is working well. My filenames remain suitably cryptic and space free!:-)


7  DAM Stuff / Naming Issues / Re: Folder Names - spaces or not? on: November 19, 2009, 12:24:44 AM
Hi Peter,

I'd be intereted in knowing the circumstances he sees issues I've done some testing at this end and not found any problems yet. Although I do suspect that CLI commands that need a FOLDER path without an ending filename as an attribute might get confused if you don't add a final \ or enclose in ""... I just don't tend to use many of those. My habit...for years now...when using a CLI in a deep tree is to CD first then issue local commands rather than specify long folder paths as an attribute.

And the ONLY reason I have used ANY CLI commands since I started this thread...other than TESTING for troubleshooting IP configurations and envirnoment variables. It turns out I really do not use it for folder/file management any more...I have better solutions for everthing that I used to resort to the CLI for (xcopy, bulk renaming and so on). So although a shortcut to the CLI is aways on my startup menu it is for a few system issues rather than file handling.

In short, after testing I feel pretty comfortable using spaces in folder names in Vista and Windows 7 and risking CLI issues since I really don't use it any more for that purpose.

But I always welcome specific advice about stuff I don't know! :-)

8  DAM Stuff / Naming Issues / Re: Folder Names - spaces or not? on: October 23, 2009, 09:10:46 AM
Hi Bob,

Hmmm...a moment of pause there...I do, on occasion...resort to the CLI because I'm a craggy old f**t that grew up that way and still find it easer sometimes! :-)

However I am on Windows (Vista about to go to 7) and the Windows command line environment has provided support for long folder and filenames including spaces for a long time now. And inextremis I can always resort to the good ol' 8.3 format names too...they still work in parallel with the long names in ther CLI (actually to be fair I haven't tested that in Windows 7...but I suspect it still will).

The only restriction I have had issues with in the recent past is not spaces but the maximum path+filename length with deep folder trees. Also on occasions the different standards applied (Joliet for CD's is more restrictive that the OS for example). Allowing spaces can encourage profligate use of characters in the folder/filename which could bump into these other limitations.

However the curmudgeon in me usually prevails and I tend to use concise names. These darn youngsters who never had the "discipline" of 8.3 just waste characters willy nilly you know! :-)

9  DAM Stuff / Naming Issues / Re: Folder Names - spaces or not? on: October 23, 2009, 07:34:29 AM
Hello again John,

Excellent points as usual!

OK, for my archival folder names which are only ever going to be on my own media I think I'm going to loosen up; but as you say keep the structured part with underscores.

My filenames for internal use are entirely structured (no freeform text) since I use folder location, metadata and keywords via both LR and Bridge to search so I don't need descriptive filenames. Filenames for external use frequenly ARE posted to the Web so a very good point there...I will continue to cling the underscore for those.


10  DAM Stuff / Naming Issues / Folder Names - spaces or not? on: October 23, 2009, 02:32:20 AM
Hi folks,

My main bucket folders are organized by year with no descriptive text so no issues there, but at the lowest level in the tree I append a brief description of the shoot/project. Thus far I have always used underscores in place of spaces everywhere but I am starting to think spaces after the main bucket identity might actually make sense moving forwards.

By way of example for a recent shoot my folder names are of the form:

but I am considering
ORIG_005_2009/ORIG_005_091011 WWRR Recce/
DRV_005_2009/DRV_005_091011 WWRR Recce/

A small issue I know...but one that keeps nagging at me. So what do we think about giving in to using spaces in folder names (and filenames for that matter)? In the past some OS's couldn't deal with them so an underscore was a sensible precaution...but all the modern OS's that I am ever likely to use now support spaces and that sort of feature is not likely to go away again since it would cause mayhem with most users existing data.

Is it maybe time to throw caution to the wind on this one?

11  DAM Stuff / Keywords and Controlled Vocabulary / Re: Support for CV in non-keyword IPTC fields? on: August 07, 2009, 07:44:42 PM
Hi Peter,

Oh yes, I do realize there are a lot of challenges, and of course I do still choose to use LR2 over the others...for now anyway.

I also agree on your incompatibility priorities...if only because I am using keywords for location right now and I've made my peace with it.

Only managing ONE CV has it's benefits too!:-)

And being a dyed-in-the-wool database geek I acknowledge that a LOT of creative solutions in many domains s*#$w up their databases and need multiple goes to get it right. That includes a couple of my former employers! There is stuff out there I was involved in but am not exactly proud of what is under the hood! :-/  Rules Pragmatism KO (it's close know what I mean;-))


12  DAM Stuff / Keywords and Controlled Vocabulary / Re: Support for CV in non-keyword IPTC fields? on: August 07, 2009, 08:55:35 AM
Hi Peter, are a very generous man Peter. Having worked in the commercial software business I can only make two observations:
  • While you are absolutely correct that there are legal and logistical issues surrounding releasing aything as part of an official "suite"...
  • ...that in no way prevents development groups communicating to implement common features, even sharing code modules.

The former is a marketing/product management choice; the latter is a development choice. They are not mutually exclusive.

And I understand creating products by flying just under the radar...I've been on teams that have done it. But once it is out of the barn that changes. And while you are building you can do so planning for the fact that one day it WILL be out of the barn. If it never makes it out then it doesn't matter anyway. And "borrowing" modules from other teams is actually a great way to build these products since they are always under funded/ don't fly under the radar without that!:-)

So I admit that I am a little less sympathetic. Sorry.

13  DAM Stuff / Keywords and Controlled Vocabulary / Re: Support for CV in non-keyword IPTC fields? on: August 06, 2009, 07:36:53 PM
Well, Lightroom is not part of the suite...

Hehe...and that is the excuse Microsoft has refused to sette for SO well with their toolsets. Although it has to be said it takes them a while to assimilate new acquisitions into the collective! :-) If it wasn't for PS and Bridge being the lead I would probably switch from LR to EM...I am tempted.

I occasionally look back to the old days with WordPefect, Lotus 123, Harvard Graphics, dBaseII and so on (or even earlier, I am sad to say I remember VisiCalc quite well:-)). Our expectations have come a long way largely due to those boring old fast followers like MS! You want to find fault...but they do keep setting the bar quite high don't they?:-/

14  DAM Stuff / Keywords and Controlled Vocabulary / Re: Support for CV in non-keyword IPTC fields? on: August 06, 2009, 03:12:45 PM
I sort of agree Peter,

But what I generally do is START my workflow in Bridge as part of my ingestion process. That is where I rename, apply bulk metadata and bulk keywords, do preliminary culling and rating, apply overall and sometimes sub-group RAW adjustments including preliminary color balance and pre-sharpening.

THEN I  archive the remaining raw files, convert to dng and import those into my catalog (I use LR).

So really I want my file browser and my library to use the same CV's, ratings, categories etc...ideally for keywords, locations etc. In particular a proper CV for the locations would be great. I do not want to use my library for the preliminaries...and I don't want to use my browser as a library. Both seem to try to hard to do both.

As things stand the only sharable CV I have is keywords so after much playing around a few months ago I now just live with my location data in keywords. At least that gives me an  integrated workflow (a long as I keep the Bridge/LR keywords synchronized).

I am very surprised Adobe hasn't done a better job of this for us. After all one of the primary advantages of a suite is supposed to be cleaner integration.

15  General / General Discussion / Re: TIFF vs PSD...again! on: April 20, 2009, 12:45:03 PM


That's the clearest explanation I have found anywhere!

Oh...and yes I did test it...including launching the TIFF edit from within LR2.3. All the information was indeed intact unless I had made further adjustments in LR when there were a couple of gotcha's – but that is not unreasonable in the circumstances! :-)

The test file was a 16 bit image with mulitiple layers and nested multi-layered 16 bit smart objects with smart filters and layer properties against the smart objects at both levels.

For reference in this test on the complex image with additional LR adjustments on top:
  • Edit a copy with LR adjustments worked OK but it was only the flattened image.
  • Edit a copy failed - it would not open. But this MAY be a LR2.3 vs CS3 thing...I haven't put CS4 on this laptop yet so it's ACR4.6 rather than 5.3.
  • Edit original worked as advertised with all thelayers intact but did go through ACR first which surprised me and messed with the colors a bit.

And thanks to your explanation the file sizes even make sense:
  • PSD with compatibility turned off ~170MB
  • PSD with max compatibility AND TIFF with ZIP compression ~210MB (so close to the same that the difference is not worth worrying about)
  • Uncompressed TIFF ~270MB

I'm convinced!:-)

And now I finally understand the key concepts I feel comfortable with making a decision...layered TIFFs for the archive (long term files) and PSD without max compatibility for work in progress (short term files) it is!!

Thanks again.

Pages: [1] 2 3
Powered by MySQL Powered by PHP Powered by SMF 1.1.11 | SMF © 2006-2009, Simple Machines LLC Valid XHTML 1.0! Valid CSS!