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: DouglasUrner
The DAM Forum
Welcome, Guest. Please login or register.
October 31, 2020, 08:22:06 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  Software Discussions / ImageIngester and ImageVerifier / @exif.usercomment in II on: November 29, 2011, 12:57:31 AM
I thought I'd used the exif.usercomment field to name files in ImageIngester. I was trying to show a friend how to do it and can't find itů

Does anybody know how to do it? Or am I loosing my mind?
2  Software Discussions / ImageIngester and ImageVerifier / Re: Changing file extension to lower case on: October 10, 2009, 10:57:06 PM
If some part of your workflow runs through the Mac you could use Automator and folder actions to change the extensions to lower case. That's how I've been doing it.

3  Software Discussions / ImageIngester and ImageVerifier / Re: Ingest from iPhone on: October 10, 2009, 10:41:54 PM
Sigh, I would have sworn I had it working at one point (and II does get launched, much as it would if a inserted a CF card). Just hoping that somebody would have dealt with this and know a solution.

Thanks, Doug
4  Software Discussions / ImageIngester and ImageVerifier / Ingest from iPhone on: October 10, 2009, 10:12:07 AM
Has anybody found a way to ingest from an iPhone. IIP launches when I connect an iPhone to my computer, but says "No image card mounted."
5  Software Discussions / iView MediaPro / Re: Microsoft Acquires iView on: June 27, 2006, 12:50:24 PM
Keep in mind that there are essentially no initial investors in iView, other than the engineering team that Microsoft has now hired in this purchase.  And iView is really their baby.  Yan has put too much into the software to want it to die: this is not an "exit strategy" for him, although it certainly enables him to realize the gains he has earned from ten hard years of work on the software.

For many small products the developers are the initial investors, and for them I am very happy.  I hope they did get a good reward for their years of work and for the truely great product they developed and for the excellent support they provided.

In any case, if Microsoft screws it up, it really would not be hard to get your work out - to portfolio for instance.  I could take all the metadata I have created for my 150,000+ file out in less than a day's work.  The only real barrier to exit, is that there is nowhere better to go.

Just keep your eyes on the export facility and make sure that it still works . . .

My concern is that it is low priority for Microsoft and I could see that it wouldn't get a lot of regression testing.  Or worse they could decide that it was no longer a feature that belonged in the product.

6  Software Discussions / iView MediaPro / Re: Microsoft Acquires iView on: June 27, 2006, 12:13:49 PM
An 'unlimited supply of engineering resourses' rarely (if ever) makes a product better -- but it usually makes it bigger.  . . .   Unlimited engineering resources produce unfocused products.

Tis only too true Sad

I think software quality is almost inversely related to company size, or at least to development team size.  iView has been wonderful in their responsiveness to their user community.  I really hope they can hang on to this.  Fortunately they provided us with a way to get out.  Just be sure to watch your back and make sure that you do backups before upgrades and test the metadata exports after updates.

7  DAM Stuff / Hardware Discussions / Re: Hard disks for Archival storage [Re: DVD Selection and Storage] on: March 27, 2006, 02:19:37 AM

For those of you who want to play a copy of the home game, you can't get the software to do WORM on spinning hard disks.  But you can do something close on the other points.

Mike, wouldn't creating the files as read-only in a directory where only the archive process has write permissions get you pretty close to WORM?  Obviously somebody with stupid, errr make that super, user privilages could still make a mess, but you'd have something between you and the great bit bucket in the sky Smiley

8  DAM Stuff / Hardware Discussions / Re: HDs - How Full is Full? on: March 27, 2006, 02:10:42 AM
I was thinking of the archive drives as read-only (or more accurately write-once), I don't know if you can get the OS to enforce this for you, other than by making the file modes read only -- but if I'm thinking about this right once you archive a file you're not likely to be changing it.

Well, thinking about it, perhaps metadata would get added and pushed into the file, but even so on a modern disk even a 100 MB file is less than 0.05% of the disk capacity.  You're just not going to see it in the available disk space Smiley  So I think you would still be quite safe filling the disk to near capacity.

If you do a bunch of rewriting of files on the archive drive when the drive is filled to near capacity then the disk layout will get scrambled, but that will get cleaned up when you move to new media and on disks with big caches I'm not sure if you'd notice the performance hit anyway.

As a more practical matter the disk is going to be full when you reach a sensible dividing point in your archive.

9  DAM Stuff / Scans and Camera Scans / Re: Camera Scannning rig on: March 27, 2006, 01:57:13 AM
The setup pictured in your book appears to have a nice, long tube firmly attached to the back end of the copy unit. Do you know what model or part number it is? Or was the tube part of the adaption to your camera.

The Nikon part is an ES-1.
10  DAM Stuff / Hardware Discussions / Re: DVD Selection and Storage on: March 19, 2006, 12:26:33 AM
Has anyone reached a conclusion about which DVD media are the best "bet" for longevity?

There was a Library of Congress or National Archives paper on this, I think I've got a PDF of it, I'll see if I can find it -- hmmm, guess I need to manage some digital assets . . .

Practically speaking the answer is to use Taiyo Yuden CDR media and either MAM-A (gold) or Delkin gold DVD media.

11  DAM Stuff / Hardware Discussions / Re: DVD Selection and Storage on: March 19, 2006, 12:20:51 AM
Most of the comments that I've seen from VERY professional photographers are that they are inclined to skip removable media altogether and, because of the dropping cost of HDs, go directly to HDs.

Using hard disks for archival storage is attractive, both from the point of view of cost and ease of bringing data back on line -- but there are substantial risks.  Consider dropping a DVD and dropping a hard disk.  You also have many more eggs in one basket with the hard drives, and I fear greater possibility of discovering a hardware incompatibility a few years down the line.

So I think the "belt and suspenders" approach of keeping your archives on both removable media and hard disks is a very good idea.  It also means that you have to have a failure of two very different kinds of media before you've lost your images.  For sheer paranoia I'd be tempted to use two different writers when making my DVDs -- but I'm still on the fence about how paranoid to be.

12  DAM Stuff / Hardware Discussions / Re: HDs - How Full is Full? on: March 19, 2006, 12:10:42 AM
I've spent years administering UNIX systems and now Macs as well.  Free space on a file system gives the OS room to work to place your image data so that it can be written and retrieved quickly, as the disk gets full data needs to be placed less than optimally and access slows down.  For an archive drive, practically speaking, this just doesn't matter.  The data on the drive isn't going to move around much, if at all.  You aren't going to read the data that often either, and since you are likely only writing it once the OS has a pretty good chance of getting the layout close to optimal (since it isn't trying to figure out how to work around existing files as it writes new ones into the "holes" created by deleting old ones).

So for archive drives, I'd say fill them full (100%).  On your working drives some free space will help with file i/o -- modern UNIX systems reserved space for this (by default about 10% of the drive capacity) so that it was not possible for mere mortal users to fill the drive beyond the point where performance was starting to hurt.  I'm not sure if the Mac HFS+ file system does something like this or not.  Peter, I think you're fine filling your drives to within 10 GB.  Frankly I'd go farther than that.

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!