Lightroom’s Library view showing multiple 120, 4×5, and 8×10 raw drum scans.

What’s happening?

Only a few years back, most companies stopped making film scanners. The game was up; scanning equipment no longer pulled a profit. The future was in digital capture and the world marched on without looking back. It left educational institutions in a pickle. They were already reeling from high silver costs and a change in photo curriculum. Suddenly companies stopped updating software for Intel chips and repair service on older scanners dropped like a stone. It put pressure on the education world to go all digital and those ripples were felt everywhere. For us high-end scanning labs that were outside of the educational “prosumer” world, we fared ok although young clients were coming to us with 8 megapixel files instead of 40 megapixel (equivalent) 6×7 film. We already went through this in the early 2000s when companies stopped making drum scanners. Over the years, most of us learned enough about our various drum scanning machines to fix the beasts ourselves. Third party service vendors, mostly past employees of the very corporations that build the crazy things in the first place, took care of the rest. But recently the support has slipped and it gets harder every month to maintain high-end equipment. Today, prosumer scanners are taking the same track but at a more accelerated pace; everyone feels the heat including professional photographers who prefer 35mm film . . . . .

Read the full article on The Agnostic Print –>

Well. It’s been quite a technical hayride the last four days. It all started with OS X Snow Leopard. I had built a raid system on a Mac Pro. I have a system HD and a basic 3 hard-drive raid running 1.5TB Barracudas (Not enterprise level. We don’t got the money.) I ran it RAID zero and let everyone know that it was for temp projects only. Then I time-machined it and scheduled the backup to run at 4am each morning just so most recent projects are saved (maybe a week’s worth or so.)

In the back we have 2 LACP 1Gb ethernet ports for 200MB of duplexed bandwidth. I’m going to add another 2 ports soon and another hard-drive to the RAID array. Needless to say, the thing is pretty peppy. It takes about 3 seconds to open a 300MB file off this server onto an iMac with Photoshop. Opening the same file right off the “Artbox” server takes less than a second.

But then we ran smack into a problem. A few students incorrectly converted their Canon 7D footage to ProRes 444. This is a way big file format and for some weird reason it totally freaked out AFP file sharing (the protocol we were using to host the server.) Whenever this 444 project was opened, all the connections on all the other client computers dropped. The wheel of death came next and students started loosing work and getting frustrated.

So I stayed up late last night and rebuilt the server using OS X Leopard Server. This lets me add processor threads to to Apple File Server. I brought this to 602 threads and brought my TCP ACK delay to 2 on all the machines. This helped matters but I was still sending out way too much bandwidth. A simple ProRes 422 LT stream was taking up 60 MB/s of bandwidth. Totally stupid.

Eventually I got it into my thick noggin that the problem was not AFP settings but it was the protocol itself!! I’ve been a diehard AFP believer for over a decade, but it was finally letting me down. OS X just kept dying whenever the Artbox share was canceled.

So in the end I turned to NFS as our prefered protocol. I also turned on Flow Control and Jumbo frames on all the client computers. The result? Right now, as I type this, we have 10 people editing live with 1080i resolution files directly off the server using only 3 raided hard-drives with zero problems. For the cost of three HDs (less than 500 bucks) we have a system that runs fast enough for an entire production studio.  Thank you Mac Pro. Thank you NFS. Fuck you AFP.

Now you know what I do every day.

Well. I’ve hunted long and hard for a soft turn-off to the mDNSResponder in OS X broadcasting all sorts of junk all over the place . . . I use ARD for a bunch of stuff (camera raw updates, remotely helping students and faculty who have a problem in the digital lab, debugging printserver errors, updating the systems, etc.)  However, I hate that screen-sharing is broadcasted throughout the building’s network showing up as a list of computers on any Leopard/SnowLeopard computer that is on the same network. Well, with Snow Leopard, the option to turn off broadcasting without actually killing the mDNSResponder daemon is here. For anyone who has SSH or ARD (please note, ARD needs to have legacy VNC turned off and only local admin user for authent to keep it secure + required encryption.) this is a nice little security upgrade. Instructions below:

Using compressed asr images, a server with dual gigabit ethernet and fast raid setup along with gigabit router and mutlistream casting, it’s possible to install an entire 52 gigabyte system image (think CS5, CS3, all other graphic applications and preferences, Final Cut, etc) in under 14 minutes.  Whoa!!!

I figured out how to do it.

1. Jailbrake iPhone and install AFP (netatalk).
2. Connect to shared Wifi access point and log in to iPhone as root.
3. Go to /var/mobile/media/DMC10/APPLE (I’m forgetting the exact folder name)
4. Add applescript action to folder to copy all new files from this folder to a folder on your desktop. Let’s call that folder “live”
5. Open Adobe Bridge and navigate to the iPhone photo folder. (Bridge forces the Finder to auto-refresh AFP mounted folders. It doesn’t do this by itself.)
6. Open lightroom and set auto-import settings to point to the “live” folder on your desktop.
7. Take a photo and watch it show up in Lightroom. This lets you take photos from as far away as your wifi can go. If you hook your AFP connection up through a VPN server, you could be taking photos over 3G in California and have them show up live in Lightroom in Vermont.

UC base fluid found and ordered today. Looked up regulations on phlebotomy. Disturbingly little. More on transportation of blood through the USPS. Looking for an artist doctor who is willing to pull 500ml of my blood for printer testing. Will build a septone monochrome print environment with megenta ink first.

Two nights ago I finished doing test photos. Conclusions for Fomapan 100. ISO 50 with 13 minute develop gives full 13+ stop range. Great scanning film because it is to thin! Took photos of Will Blackwell (my cousin) for first blood print. Need to learn how to take blood. Developing tonight.

I am going to go out on a limb here and talk about the future of Digital Asset Management. I believe the reason why DAM software is not working well for most people is for a few really big reasons.

1. There are too many non-compatible non-cross-platform solutions out there.
2. Many of the best solutions are not open-source. That makes many institutions unable to buy contracts for the use of the software. The institutions are also dependent on outside programers and this is always a risk.
3. Many solutions don’t implement robust infrastructure. That is to say, the time it take to query and load an asset takes way too long for the DAM software to be useful. This is often a fault of infrastructure problems at each particular institution. Many institutions haven’t funded gigabit switches enough. They are slowly adding these switches to critical network nodes, but the increased bandwidth hasn’t trickled down to the end users yet. Added to this is the need for large enough servers to through out the data fast enough.

The solutions? Well, there are a few obvious ones.

1. Go with an open-source, standardized, digital repository system like Fedora Commons or Dspace.
2. Add an extendible and “sexy” front and back end online GUI for creating user accounts and the like.
3. This is critical. Create a FUSE-based File System “glue” layer between the repository and the end user. Why do this? Simple.
a. Increased unlimited security. The file system can be upgraded with various encryption methods very easily.
b. Platform independent.
c. Open source.
d. This is the best of all. End users can use WHATEVER desktop DAM solution they want to use. All they have to do is point their DAM software to a hard-drive on their computer and away they go. They can be importing files into Final Cut live off a Fedora server. They can be scrolling through Art History slides from the Thirties in Adobe Bridge. They can run a spotlight search on the entire archive. That search would be translated into a Fedora query and return as a Spotlight result. Boom, done.

Users would be able to use their preferred applications. The ones they use all the time. The documents they would be working on, however, would be organized, archived, sorted, and versioned, somewhere else. This increases security, decreases the risks associated with HD crashes, increased collaboration (just imaging typing in someone’s user-name in Spotlight to see their shared MS word docs right in a hard-drive on your desktop), and decreases the amount of time it takes to train everyone on some clunky, underdeveloped, solution that nobody will really use.

You want to archive 3000 songs? Drag them into a folder and the rest gets done automaticly. If iTunes can scrub through metadata on a drag-and-drop, FUSE can do it to.

You want to see multiple versions of a file? Do a search of the HD.

You want to manipulate the photo? Open it in Photoshop and do that.

You want to collaborate with a peer on a document? Set the permissions directly in the file with Get Info or any other platform independent permissions window.

The possibilities are endless and the learning curve is minimal. So that’s where the future of DAMs lies. Not monolithic solutions, microlithic solutions with solid translators in-between. Imagine two people working on a digital archive at the same time. One person is using Adobe Bridge on a Mac, another person is using a normal browser on a PC. They are doing the same thing in their preferred way!

1. Create a unified content front-end and middle-end system based on XML.

2. Create a unified live-data collaboration GUI set for faculty/staff/students and anyone else connected with UVM. This can be built on Flex and Spry frameworks.

a. Email –  Have support for full unlimited archiving and RSS feeds etc. The web gui should be Air compatible and rival OS X Email for search capability. That means live searching.

b. Calendars. Everyone at UVM should have a calendar. Not just faculty/staff. Students need that too. Use the opensource Darwin Caldav server. iphone, smartphones, and all sorts of applications and platforms can connect to it. Build in a Flex front-end to the calendar for admistration. Also a Spry front-end for UVM’s site.

c. Create a real database-driven content management system for UVM’s many websites that fully seperates design markup from data. Again, build the data from XML. This should be built upon an opensource CMS like WordPress or Drupal.

d. Create a real digital repository built on the combined force of Fedora 3 and Dspace with a flex-frontend gui and suitable Spry-like web-based front ends for students and faculty to search.

e. Give access to web developers and faculty to connect departmental websites with the DR content.

f. Give access to web developers and faculty to connect departmental websites with any DB content at uvm including calendars, news, rss feeds, etc. Half of this is done, but there is no centralized pool of data for retrieval.

g. Looking forward, we realized that more and more data will run in a live-update form. Any new modifications to sites should include live listening handlers for data updates. All of this is resource intensive, but the web will always be so.

h. Add mobile application layers to any and all portions of online-accessable content on the UVM infrastructure. This includes Calendars, Email, websites, student backends, facilities management, etc.

i. Create an encryption and security protocol for all new content and infrastructure that includes regular security updates of open-source components and regular penetration testing of all components. Closed source components should be minimized and isolated to non-line communications as they are a security risk that is hard to react to when compromized. That means getting rid of closed-source collaboration software that costs too much money, does not get updated because of financial problems, and can lead to massive data vulnerability.

+ much much more.