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: Duncan Skelton
The DAM Forum
Welcome, Guest. Please login or register.
October 28, 2020, 09:43:02 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]
1  General / Photo Blogs / Climbing photography blog on: October 18, 2010, 06:38:44 AM
My website is dedicated to rock climbing photography. My blog promotes climbing photography and digital workflow issues.
The blog is here: climbing photography blog

Your thoughts and comments are welcome.

reagards
Duncan.
2  Software Discussions / ImageIngester and ImageVerifier / Re: Final destination filenames fail with Primary that includes path on: August 09, 2009, 02:15:20 AM
Hmm,
So when I looked at this again this morning I see an obvious answer  Wink

The 'primary' folder should only be used to specify the drive, not any fixed part of the path. (Will look again at the documentation to see if it fooled me, or if I just didn't read it properly).

The 'folder arrangement' is the place to specify all parts of the desired path, both fixed and generated. I click the 'show detail' checkbox to get at the editor and this solves my issue. Hopefully noone else will fall into the same schoolboy error ! I think I was overlooking that checkbox.

Regards,
Duncan.
3  Software Discussions / ImageIngester and ImageVerifier / Final destination filenames fail with Primary that includes path on: August 08, 2009, 06:03:38 PM
Hi
Just got round to grabbing the latest IIP and setting it up.  (IIPro 3.3.02 on WinXP.SP2)
I immediately find that if I specify anything more than a root drive for Primary it fails to add a trailing slash, thus failing to correctly nest sub-folders (client name for me).

Here's my setup.

Primary: W:/1-Landing_Zone
Folder Arr. {@client.name}/{@project.name}/{@numberrange}
eg, Watkins/Wedding/0001-0200

Actual paths generated...
W:/1-Landing_ZoneWatkins/Wedding/0001-0200

Desired path
W:/1-Landing_Zone/Watkins/Wedding/0001-0200

If I limit primary to just a drive specifier the paths generated include the correct sub folder arrangement.

Anyone else seen this? Any ideas? What have I missed?

Kind regards
Duncan.
4  Software Discussions / Scripting / Re: Image unique ID from digital camera [EOS] into a custom field on: September 21, 2007, 12:10:53 PM
Hi John.
I understood you were only adding script to the template file, but I'd missed a trick. I'd assumed you were only adding the script to the media template, and that it wouldn't work for the index template. I've just experimented and found it does exactly the right thing - as you said it would ! Perfect ! My assumption that it wouldn't work for the index file is what led me to figure I'd have to hand edit the generated/compiled index pages - but that's simply not true  Grin Cool.

Loosely speaking then my index template could look like this....
         <div id="gallery">   
            <span class="index">(iView:Index)</span>
            <ul>
               (iView:IndexRowStart)
               (iView:IndexColStart)
                  <li>(iView:Preview)<\br />(iView:Filename)
                  </li>
               (iView:IndexColEnd)
               (iView:IndexRowEnd)
            </ul>
         </div>

(the <\br /> was supposed to be a regular html line break but I couldn't get it show without being processed as such so escaped it!!!!)

...and one can replace the direct reference to (iView:Filename) with your javascript or PHP equivalent.  (I spotted only recently that you can ask xMedia to generate appropriate file extension -.htm / .html / .php ...) This is exactly what I was looking for.

The HTML generation and templating capabilities of xMedia/iView is a real winner - very powerful.

I take your comments about the Theme Fields on board as well - that adds an ability to parameterise the HTML generation which gives even more flexibility. I've just started to see the potential here.

Thanks for your help. I think I'm there now !
5  Software Discussions / Scripting / Re: Image unique ID from digital camera [EOS] into a custom field on: September 20, 2007, 03:40:11 PM
John,
Those are all good points, and I'll take back the sledgehammer comment. I'll take a look at how the PHP would look to compare to the javascript.

This design will work well with my current solution - I only display the filename of interest on the media pages, and not the index pages. Since there is only 1 image per media page then this will work. (The javascript above would be pasted into the relevant part of the media template file).

If it was desirable to get these calculated filenames displaying as thumbnail titles on the index pages then more work would be needed wouldn't it ?  For me that's not worth it currently. Having xMedia generate customised HTML Galleries is a great time-saver, and you lose a lot of value if you end up having to hack the 'compiled' HTML index files that result.

Thanks again.
/duncan.
6  Software Discussions / Scripting / Re: Image unique ID from digital camera [EOS] into a custom field on: September 20, 2007, 02:15:23 PM
John,
Thanks for the quick response.
Yes - xMedia is doing the grunt work with the HTML galleries.
I can see how your Javascript is doing the necessary there - and I have to admit I hadn't really thought of that. I could use that solution. I guess there is a PHP alternative to do the same thing server-side. Thanks for the guidance.

It does seem like a sledgehammer approach. Does that mean that as far as you are aware xMedia won't support me in isolating the unique image id like bridge ? That would seem worthy of a feature request to me. If this is indeed the case I'll try emailing the support team.

Thanks again.
Duncan.
7  Software Discussions / Scripting / Image unique ID from digital camera [EOS] into a custom field on: September 20, 2007, 09:31:05 AM
Hi,
I use long filenames for my RAW/derivative files as per the DAM book suggestions. When it comes to generating HTML galleries though I think these long names are too much for clients to handle. When they pick images from their gallery and communicate them to the photographer they need to do this with minimum faff.

Ideally the images should just have a short unique id that the photographer can immediately match to the correct master image in the catalog/archive.

It strikes me that the unique image id generated by the camera is the right thing to use - the chances of the number wrapping and producing a duplicate id within the space of a single shoot is practically nil. Adobe Bridge exposes this important metadata as part of the file rename utility, and so I had assumed that iViewMediaPro/Expression Media would grant similar access.

However, - I don't see a way of getting at it within the HTML Template documentation, and assume that resorting to scripting is the only way.

The best I've done so far is to Batch Rename the gallery set of images using the find/replace options to manually strip out the irrelevant bits of the filename just leaving the unique image id. (See http://www.georginashellard.com/client/portrait/bld1/index.html)

Anyone got any ideas, or alternative ways of approaching the same problem ?

Many thanks.
duncan.
8  General / General Discussion / Re: When/how to name RAW and DRV buckets on: August 03, 2006, 06:43:31 AM
Brilliantly obvious, thanks.
I've not really played around with the iView physical folder filters and that stuff. Makes perfect sense. Thanks.
/duncan.
9  General / General Discussion / When/how to name RAW and DRV buckets on: August 03, 2006, 04:39:24 AM
The DAM book suggests naming RAW buckets as  RAW_[nnn]_[yymmdd] where the date is taken as the date the last original was added to the bucket, making it full. I've just got round to filling my first buckets.

So,  I download CR2 raw files, process them as suggested, and when ready I put them away into the next available bucket (which I call RAW_[nnn+1]_"xxyyzz" because it is not yet full). Having put the converted DNG into the bucket I catalog it using iView.

Now when the bucket is full I have to rename the bucket to give the correct filled date. Now my catlaog has lost its media - becuase they have effectively moved. iView will list all missing references, and I can point it to the new path and everything is restored.

But this is a couple of extra manual steps every time I fill a bucket. (And because Im faffing about with folders and names there's another chance I'll cock something up  Smiley).

Presumably, the bigger my catalog grows, the longer it will take to find missing references.

So my question, what are the benefits of naming the RAW buckets by date filled ?

I have started naming by date started - eliminating these additional steps - and it seems to me fewer steps is better. I don't see that this approach loses me much added value.

Any opinions ?

/duncan.
10  Software Discussions / iView MediaPro / Re: Clarification about cataloging on: August 01, 2006, 05:42:10 AM
Fast respone - thank you.
Glad I'm on the right track.

Ive found so far that the DAM approach challenges the way I have worked previously. So I took the advice literally and applied the method strictly. Now that I've gone with it quite a few times its only now that I can start to spot the chinks in my understanding and see where my process feels awkward. It really works, it works well enough to warrant the energy required to make it as slick as it can be.

The importance of the 'drop folder' is only now becoming apparent to me.

Thanks again.
11  Software Discussions / iView MediaPro / Re: Can't display layered psd files in Media Tab. on: August 01, 2006, 05:32:14 AM
I see this same phenomenon.
The PSD image was edited with Adobe Photshop7 on Windows XP.
It contains a mask stored in an alpha channel.
I catlog the image on a PC (XP pro) using iView Media Pro 3.n.n
Both the thumbnail and the main image display as shown in this post, with the masked area appearing blank - it looks cruddy.
I have saved the PSD with "maximise compatibility" checked, and iView is configured to use the alpha channel.
12  Software Discussions / iView MediaPro / Re: Clarification about cataloging on: August 01, 2006, 04:55:22 AM
Hi,
I was about to ask exactly the same question. I currently have 1 catalog for RAW orginals (DNG conversions) and a 2nd catalog for all the derivatives (_master, etc...) Having worked with this for a couple of weeks I now feel that this way of working is creating quesitons.
I reread your excellent book yet again, and saw that you do indeed say that you store all your derivatives in a seperate catlog (and I infer the RAW goes into one of its own).

So I've been using this and found questions arising and getting the feeling this is counter-intuitive.

All the RAWs I am left with after a first pass edit get converted in DNG and dumped into buckets and put into my iView catalog.
A subset of these RAWs (1 start and above) I usually make a _master derivative of. Currently I use photoshop PSD as my master file format. All derivatives go into a second catalog.

Now this is where my issue starts.

It seems reasonable that the derivatives catalog is where I will spend most of my time. But how do I know if I have a derivative of a particular image ? I have to look at my RAW catalog to see everything that I have shot. When I locate an image in there how can I tell if I have made a _master derivative or not ? I could get the filename, switch into my derivative catalog and search on the filename base - but that seems like extra effort.

Elsewhere the book offers guidance that one should use as few catalogs as possible - seems reasonable, and logically this would be 1. If all content-based indexing is now in the realm of the catalog software (and not the filename/folder structure) then surely it follows that all images should be in the same catalog. Using multiple catalogs means distributing the content-based index and we move back towards the pre-DAM methodology.

I'm not professional so don't have real clients. But I'd like to be. It would be useful to see the DAM methodology expanded to cover some basic use patterns of the catalog software also. For 1 shoot say, I guess I would expect to see a catalog set, with a number of sub-folders: RAW, masters at a minimum and more depending on the nature of the job/delivery.

So - I fell I want to put everything into a single catalog. Please someone confirm if this is a reasonable thing to do since it conflicts with the guidance the book implies.

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