Posted by Rande Simpson on Tue, Mar 09, 2010 @ 11:00 AM
Digital Asset Management Systems play a huge role in fundraising efforts for non-profit and other organizations especially when a natural disaster strikes an area.
The news media provides an important role and is usually quite good at getting the first images out to the world and perhaps follow-up coverage for about a week, but then it becomes “old” news.
It is the photos that are distributed by relief organizations who are onsite that tend to have lasting effects. People around the world are interested in seeing how organizations are rebuilding or providing relief to people affected by the disaster.
Photographs are usually emailed or sent via some type of electronic transport (like ftp) from the disaster site to the organization’s central DAM. From there they may be posted on a website, or distributed directly to people who are known contributors.
Images may be used in newsletters that go out to potential contributors so they can see how their favorite organization is helping, whether it is providing medical help, shelter, food, or perhaps religious guidance.
After the earthquake in Haiti, Habitat-for-Humanity International posted images in their Merlin DAM system of Haitian women carrying 5-gallon bucket shelter kits that consisted of a crowbar, a rope, a tarp, nails, a trowel, a handsaw and hammer and work gloves. Contributors or potential contributors from around the world can see how their financial donations do have a direct impact on providing temporary shelter to people left homeless from the earthquake.
Save the Children’s director of field technology said their Merlin hosted digital asset management system allows greater access for the Save the Children Universe to a library of images that helps to tell compelling stories that raise funds that save children’s lives.
Images stored in an organizations’ centralized digital asset management system can easily be accessed and reused, not only for the current campaign, but for future fundraising or annual reports as well. When all your assets are stored in the same system, they are safe, secure and they are easy to find and help tell your story over and over again.
Posted by Rande Simpson
Posted by Rande Simpson on Tue, Mar 02, 2010 @ 11:00 AM
Top ten reasons you need a Digital Asset Management System
- You spend hours a day trying to find digital files that you know exist. Sometimes you never do find them.
- People phone or email you all day looking for digital assets. You wish they could search for them by themselves.
- You are worried that material you have rights to use ONLY in print, gets used on your website.
- You are concerned the wrong version of an asset gets used (the “bad” old logo instead of the new branding, etc).
- Several company offices or affiliates need access to the assets. They see you as the bottleneck.
- You are concerned the cleaning crew will spill something, kick, or pull the plug on your computer and you will lose everything.
- Your assets are spread throughout various computers and different offices. Their hardware keeps going down.
- You are spending money burning and mailing CDs of data.
- You had to rehire someone to create an asset that you had before.
- You want to make your life easier and work more efficiently
Posted by Rande Simpson
Posted by Jennifer Cox on Thu, Feb 25, 2010 @ 01:32 PM
Last week, David talked about some of the challenges found in taking photos at an event like the Olympics.
I deal with the issues at the other end of the pipe – managing the photos once they've been captured. As technology has advanced to make it easier, cheaper and faster to take and keep ever growing numbers of photos (no more kneeling on a bathroom floor praying for a steady modem line, at least most of the time), organizations are faced with the problem of managing and storing those files. If you've been reading this blog for any amount of time, it won't surprise you to hear that we think that your best plan for managing those files is a digital asset management system, right?
For news organizations, an event like the Olympics presents this same challenge, compressed into a two week long news cycle. A few years ago – probably for the 2006 Winter Olympics - our support group took calls from a few of our sites reporting that that were suddenly finding themselves running out of space. A few hours of troubleshooting later, we found that one of the wire services had increased their daily feed from about 6000 photos to over 10,000, just in covering the Olympics. Clearly there are a lot of pictures coming back.
When you are faced with wrangling that kind of volume, there are tools in digital asset management software that can help you make sense of the flood of data.
One of the best of those tools is the saved search. This lets you build a search once, save it out, and re-run it as often as you need to be able to find the data that you want. These searches can usually be as complex as you need, and can be re-run with a simple click or two of your mouse, you should be able to save as many searches as you need and be able to share them among other users as well. If a user pairs saved searches with the ability to auto update a search window, they can easily monitor new incoming data that matches their search criteria.
Another great feature for managing data is one that allows you to create projects or collections of objects. You can store objects in a project for later review or as a way to keep the best objects of a feed in one place. If the projects can be shared between users, they can also be a simple way for other team members to see which objects you've selected as the best candidates for use on your project.
One final tool that can be helpful is one that allows users to be notified when new objects matching their searches are imported into the system. This is often best for users who are looking for a virtual needle in a haystack - hoping to separate out a few small pieces of data out of the incoming flood and be notified when it arrives.
What are some of the tools you use to manage large amounts of incoming data?
Posted by Jennifer Cox
Posted by David Breslauer on Tue, Feb 16, 2010 @ 11:00 AM
While watching the opening ceremony of the 2010 Olympic Winter Games in Vancouver, I was reminded of the challenges faced during my tenure as the Photo Chief for the 2002 Games in Salt Lake City. Once the games start, it always looks good on television and in pictures. But a lot of behind the scenes work goes into making sure the “look of the games” (banners with logos, colors) is apparent in every photo and video clip.
As Photo Chief, I was responsible for the logistical arrangements for the 550 accredited photographers. It is amazing the new friends that found me because they thought I could help them get a “press pass” for the Olympics. Fortunately for me, the rules governing credentials are clearly defined, and are handled by each country’s national organizing committee. For the United States, press credentials are the responsibility of the United States Olympic Committee. That sure made it easier when a local governmental official sought me out for credentials.
I spoke with Nick Didlick, the Photo Chief in Vancouver, recently to wish him luck. We joked that if he had done his job well in getting things set up, he might actually be able to go out and inspect his handiwork first hand. I know I was actually able to take in some events, and inspect on-site how our planning had actually been implemented. Nick was telling me that at one of his venues, he was having a problem with the placement of some television cameras. I laughed, it was at the same venue I had similar problems in Salt Lake City. It was not until the bobsleigh venue (in both cases) had been built out for the Olympics that the broadcasters were able to see their true sight-lines. And of course, this meant moving the still photographer platforms—television pays the bills with their purchase of broadcast rights and takes priority when selecting camera positions. In my case, the still photographers ended up in better positions with the compromise we reached. I hope Nick fared as well.
Trying to anticipate problems before they become problems was my job. This meant lots of internal meetings with different groups, and of course external meetings with news organizations. During one such meeting, we took a group from Reuters to the downhill venue at Snowbasin. They wanted to see for themselves how to best use wireless technology to get their pictures down the mountain from where the photographers would be positioned. Only one problem with this meeting. There was snow on the hill, and the Reuters wireless expert, Bob Covington, did not ski. Herwig Demschar, SLOC’s Alpine Director was on hand, and promptly hoisted the Bob onto his back and skied him down the “Grizzly” course to each of the expected photo positions. Demschar had previously been a coach for American skier Picabo Street (1998’s Olympic Downhill gold medal winner) and had carried her down courses when she was injured, so she could visualize them even when she could not ski them herself.
Sometimes problems are solved on site once the venue has opened. At our cross country venue, Soldier Hollow, photographers were having a difficult time getting the right angle they wanted for their finish line pictures. After consulting with the venue chief, the photo supervisor for the venue had a pit dug at the finish for still photographers the day before the event started, putting cameras at ground level. It was such a great idea that it was used in both Torino and in Vancouver.
Nick, Good Luck, though I know luck has little to do with it. I hope you get to see some of the events. I know I will have one of the best seats in the house, in front of my television, because of all the planning that people like you put into it.
Posted by David Breslauer
Posted by Andrew Forber on Tue, Feb 02, 2010 @ 11:00 AM
There was a time not so long ago when databases ruled the world.
When I say “databases” I’m referring to huge collections of data, all neatly slotted into long, wide tables in precise order, last name first, first name last. Remember the phone book, neatly arranged by correctly-spelled last name, first name, and initials and stamped onto dead tree matter? And there are military service records, and credit card account statements, all nice and precise and regular, every bit organized and in its proper place. There are rules, and math, and Cod’s Twelve Laws for Relational Databases. Those things still exist, of course, and a relational database is still a great and useful invention for keeping organized, regular, disciplined data.
Great, but. It’s really easy to lose data in a relational database. Oh, it’s in there, but you have to find it. Don’t know how to spell a name? One digit wrong in the account number? The description has a paragraph in it somewhere that talks about the CFO’s villa in Tuscany? Oops, no hits. You may be out of luck.
Over the years people have come up with ways to find data they couldn’t have otherwise. For example, Soundex codes were invented to find people in databases even though their names might have been misspelled: in addition to the name of the person you were looking for in the data, there could be a code consisting of a letter and three digits, and even if the person’s name was spelled wrong you would often still be able to find it because the code was correct. You’d just have to look at more records to find the one you wanted. (And we’re talking about really old databases here – filing cabinets, in fact. Soundex was first patented in 1919!!) Soundex, in a way, was the first tool for what we now call fuzzy search.
At the other end of the spectrum there’s a new technology ruling the world now: the chaos of the World Wide Web, and the search engines we all know and love. The data is messy, and meant for humans to read: it’s not useful to the average computer program. Finding the exact thing you want on the Web is often as much a challenge as it is in relational databases, because of the mass and messiness of the data, and the breadth of the fuzzy search tricks programmers have come up with. Looking for Maggie Smith or Asok Patel? Did you mean Ashok Patel? Here are the top 5 results for that. Be prepared to wade through a lot of data.
In fact it’s unavoidable that any time you try to create a tool that makes searching easier by requiring less precision, you pay for it by having more results to pore through. The biggest issue in web search is how to figure out what the human really wanted, and understand the contents of the database well enough to deliver just that. Oh, you’re looking for THAT Asok? The guy you went to school with? Let’s try to find him through the other organizations you’ve worked with, schools you went to, friends you had in common, companies that hire people with the same education … Computer scientists all over the world are racing to find solutions to the problem on the web. The problem will only be solved, perhaps, when the computers are truly more intelligent than we are.
In electronic discovery and in digital asset management we have a similar problem, with a smaller scope. Collections are smaller, perhaps up to just several million documents. We still need the full-text search and the tools for allowing searches to be fuzzy, but we need to pick out documents by their structured data at the same time. Find everything to do with the debt-hiding corporations, but only from the Chicago office in January 2003, and don’t let Fred over there see the ones marked Privileged. This kind of work requires a hybrid of the fuzzy and the precise: loose questions and strict rules, both, letting real people answer real questions in real-time. That’s a specialty of ours at MerlinOne, and our technology continues to develop so that our customers, over time, will have the best of both worlds.
Posted by Andrew Forber
Posted by David Tenenbaum on Tue, Jan 26, 2010 @ 10:54 AM
Ever wonder how it is possible to take a photo with your 8 megapixel camera, see the file referred to as a 24 megaByte file, and then send it to someone by email and the attachment is only around 1 megaByte? How can you squeeze down 24 megapixels to 1 megaByte and not mess up the image?
The whole topic of compression is really important, even these days when bandwidth and disk space are relatively cheap, because the visual objects we create like photos and movies get larger as camera sensor resolution gets better and better. We thought it would be useful to do a blog about compression basics since some digital asset management systems manage mostly photos, and we’ll use the JPEG still photo compression as our example.
You have an 8 megapixel camera, first question is how do we start off with a 24 megapixel image? Pretty much everyone shoots color photos, and a color photo has 3 “planes” of data, one for the red content of your picture, one for blue, and one for green, and when the three planes are overlapped you get your color photo. Using some fancy math (which we’ll get into in a future post) the exposed image from the 8 megapixel sensor is used to create three 8 megapixel “planes” of the image, one red, one blue, one green, and so the output of the camera is a 24 megapixel image (and since most pixels=1 Byte of data, it is a 24 megaByte file-we will clarify that in a future post as well!).
So we start off with a 24 megaByte file, and that is pretty large, and we’d like to squeeze it down. About 20 years ago a consortium of technology companies got together and came up with the JPEG (Joint Photographic Experts Group) standard for image compression (before that every vendor used its own proprietary compression and you could not email a photo to a friend and have them view it unless they used exactly the same software you did). Let’s look at how JPEG works.
Imagine a horizontal photo showing your head and shoulders against a white background. Break it into 8 x 8 pixel squares (there would be about 125,000 of those squares in the whole image, so each is a tiny part) so that the whole image is a mosaic of those squares. Now save the top left square of the image exactly (in this case the top left square would be all white pixels of the white background). Now take the next 8 pixel square, just to the right of the first one, and this time just save the difference between it and the first square. In this case it is just another square of white, so there is no difference, and we can just save a short code to tell us the difference is nothing. As we proceed to the right, there are a whole lot of these white squares, so we only save little codes of how they differ, and save a huge amount of space in our compressed file!
Eventually we will reach the end of the top row of these squares, move down a row, and someplace near the middle we will get to the first square with some hairs in it (in my case gray hairs). Now all of a sudden our JPEG algorithm (rules) will say “Hey, this square is very different from the preceding square, so let’s save a bunch of information about the differences and then start saving the differences of the next bunch of squares from it”. And this way we will work our way through the hair, saving difference codes, and then get back to more white on the other side, where the differences approach zero again.
This same process of coding squares that are significantly identical to the preceding squares will save us space in my blue shirt, for example, so we can squeeze even more redundancy out of the data. Now and then we will get to a square with a LOT of differences from the preceding one, and we will have to save a lot of its data (we call that high frequency data: think of a crowd in a grandstand, or a crisp shot of my hair), but mostly we will hit squares with low frequency data. And on the other end, when you go to expand the file back out to look at it, that software understands JPEG too, so it knows how to interpret our stream of data and recreate the original.
It turns out there is even a quality control knob you can select to adjust the threshold the algorithm uses to determine if adjacent squares are identical or not (they actually analyze each square with a formula called a Discrete Cosine Transform and compare those). You can set the knob for absolute maximum quality, and it turns out that pretty much any natural image can be compressed 2.7 to 1 and be exactly identical to the original (“lossless compression”). Or you can set it to excellent quality, and get an average of 18.5 to 1 compression and the data you “lose” will be not discernible to the human eye. Or you can say “all that matters is a tiny file, and the quality can suffer” and you can get much higher levels of compression, but the image will start to get blocky because you can “see” the 8 x 8 pixel squares. You set the JPEG quality to match your desired output use.
JPEG is actually a two pass algorithm: the first pass does the analysis of the 8x8 squares using the DCT (Discrete Cosine Transform), then a second pass (Huffman coding) finds the most common “difference codes” and represents them with a small number, thus saving a bit more space.
By the way, the use of the 8x8 squares is why JPEG is not a good solution to compressing type on a page: any diagonal line, like the foot of this “R” will look like a stair step if it has to be represented by 8x8 squares!
The conclusion: using some clever math, with some understanding of how humans view images thrown in, we can take really excellent photos and save them in a fraction of the space they would otherwise need, saving time and money!
Posted by David Tenenbaum
Posted by James Burke on Tue, Jan 19, 2010 @ 11:00 AM
In a previous life I was a video editor for a company that pioneered nonlinear editing systems. During that time, I used to collaborate on edits with a very talented editor located in Maryland (I'm located in Massachusetts). In order to work together we had to devise a workflow where we could both edit the same video project. Keep in mind that in the early 90's most people still were using dial-up, and moving large media files over the Internet was completely out of the question.
For those of you unfamiliar with the video world, here is very brief overview of how it works: “Nonlinear editing systems” (NLE’s) edit video in a non-destructive manner, meaning the edited sequences are just a series pointers back to the full media files (as in “start at this timecode and end at that timecode”). During an edit, the original media is never actually changed - it's all just the manipulation of metadata - the metadata holds all of the instructions about the edit. When editing, the metadata of the sequence changes to reflect new timing, new sources and details on the visual effects. Much like in digital asset management systems, metadata is the key to making the system work.
As part of our collaborative workflow we decided to use this to our advantage. At the start of the project, I would digitize all of the media. The early 90's also pre-dated widespread adoption of digital video (DV), so all of our tapes had to be converted from analog component video into motion JPEG files. Once all of the media that we could possibly ever need was on a hard drive, I would copy the hard drive and send the duplicate drive down to Maryland. I would also send a copy of all the bin files which included all of the metadata about each video clip - the tapenames, start and stop timecode, number of tracks, video and audio formats and all the other pertinent information.
As we began editing, we'd both be able to work off each other's edits by emailing the modified bins with sequences (the metadata) back and forth. These bins were generally very small (a couple KB or so) and were very easy to email. The only time we'd need to send actual media files would be if either of us generated a title. The media files associated to the title were still as small as 1MB and could easily be emailed. It was best if both systems were always sharing exact duplicates of all media, including titles.
The trick to this type of collaboration was making sure that we had the most current sequence before making any changes. If one of us was to begin editing a section of the video based on a previous version of the cut, there would be problems - problems we had to deal with in a couple of instances. Since I would be mastering the final sequence, it usually meant I had to backtrack and rebuild my changes into the sequence I had received. If the timing had changed between the previous and the current version of the sequence, I would have to re-cut the changes from Maryland, to make them fit within the current version.
Once we had the picture locked down, I would prepare and master the sequence for the sound edit. Sound prep meant adding a frame of white 2 seconds before the start of picture. This flash was called a 2-pop and was used to synchronize the finished sound once it was received. Mastering was taking the sequence (that had up until this point just been metadata) and converting it to a single Quicktime movie file. The music and sound tools would work the same way as the video editing tools - manipulating small metadata files until the project was complete. When the sound was complete, they would add a sound blip to correspond with the 2-pop on the video, master to a final media file and send it back. The final step in completing the edit was to lock the picture and sound together using the 2-pop.
Without metadata this workflow would not have been possible. This data that describes the media we work with is essential in post production just like it is in digital asset management.
Posted by James Burke
Posted by David Breslauer on Tue, Jan 12, 2010 @ 11:19 AM
Back in the day when I was a whippersnapper of a photographer and was shooting film, I learned it was important to save my work. Plenty of people tried to help me be organized, and it’s only appropriate that I now pass it on by helping others save their work in my role at MerlinOne.
There have been plenty of stories of photographers going back through their film to find otherwise meaningless photos that later became important because of circumstance. Dirck Halstead’s photo of President Clinton embracing Monica Lewinsky comes to mind. A forgotten photo of an unknown person in a routine presidential rope line becomes significant because of… well, we all know why. Another less known instance was The Spokesman-Review’s (Spokane, WA) uncovering of photos of white supremacist Buford Furrow after he attacked a community center in Los Angeles. According to Larry Reisnouer, who ran their photo department at the time, they had to go across the street to where film had been relocated for long term storage to find the photos.
As a student photographer in 1976 at The Daily Texan, at The University of Texas, we learned a simple filing system for negatives: you cut your film into strips of 6 frames, put them in an envelope, and wrote an index card with the assignment information. Both the negative and the index card were labeled with the same chronologically ordered number, called a “twin check”. The negatives were filed in numeric order; the index cards were filed alphabetically by subject. This provided two ways to search… chronologically through the negatives and alphabetically in the card catalog. Finding the information that went with the negatives, or the negatives that matched the card became a simple matter of cross-referencing. For us photographers it felt like a lot of extra work – even if it did pay off when it was time to look for a picture!
Later, when I worked at the Fort Worth Star-Telegram in 1977, filing could not have been easier. At the end of any assignment, all a photographer had to do was staple the rolls of film to a copy of the assignment request form and drop it in a basket. A librarian would take care of the rest (properly filing the negatives, usually with a tearsheet of the photograph). This just transferred work from the photographers to the librarians. If photographers were the weak link, I was one of the worst offenders: it was not unusual for me to leave film draped over a hook near my enlarger or worse, hanging on a coat hook in my locker. On a regular basis, Dorothy Hooper, the photo librarian, would sweep into the photo lab to “encourage” the scofflaws to get caught up on their negative filing.
If there were other ways to throw a wrench in the librarian’s workflow, photographers always managed to find them. We thought we could impress the editors by printing our photos on 11x14 paper instead of the 8x10 we typically used. While it may have impressed editors, it did not impress Dorothy: the filing cabinets she had could not handle the 11x14 size, so our works of art were folded in half for storage.
At The Associated Press in Dallas, we were to send ONLY the strip that contained the transmitted image to the central AP photo library in New York. Local bureaus could keep the remaining negatives if they wanted to but when I was transferred to Austin (1986), the bureau was in the State Capitol building right off the rotunda, about 50 feet from the Governor’s Office. Not much room for storage there – and you can bet we didn't keep many negatives! My outtakes ended up in yellow Kodak paper boxes. I could usually find an older assignment because of the date ranges contained within the boxes.
With the transition to digital, we had to find ways to manage our digital files. Important searchable information, “metadata”, is generated as part of the assignment request process and is digitally “attached” to the resulting photographs. Other information is added “after the fact” including location, general caption information, as well as the “left to right” of individuals in the picture. A few moments invested up front in the photo-workflow adding this metadata can save lots of time later, and doesn’t require effort from others, like librarians.
Metadata lets powerful server-based systems (like those that I help people with, our MerlinOne digital asset management system) locate the right object from a collection of millions in under a second. That is a long way from having to walk to the storage facility and rummage thru boxes of negatives. Now EVERY photo has useful searchable information associated with it. After all, it’s the workflow – and even Dorothy Hooper would be proud of me!
Posted by David Breslauer
Posted by Andrew Forber on Tue, Jan 05, 2010 @ 11:00 AM
As a reader of blogs like this one, you're probably already familiar with Moore's Law. It states, more or less, that the power of new computers increases exponentially with time as the costs come down. If you look at the history of microprocessors going back to the 1970s, you’ll see that CPU speeds have doubled on average about every 1.8 years.
For those of us who have been doing software development for thirty years this has seemed like a surprisingly steady progression because, I suppose, we've been immersed in the technology. When a new, faster iteration of a key technology emerges it's often a few months before business conditions and prices come down enough that we have a reason for adopting it, so it already seems old before we get to play. It's actually easy to become jaded about how fast things are getting faster - until, that is, a jump in the state of the technology is larger and more significant than most. Then we take notice.
The most exciting thing happening in IT these days is the introduction of low-cost solid state disk drives. SSDs represent a major advancement with the potential to revolutionize database systems and particularly the search engines used in digital asset management systems and electronic document discovery.
The reason that SSDs are particularly good for full-text search engines like MerlinOne's Dox is that a large part of the work involved in creating, maintaining, and searching an index is spent moving the head of a conventional disk from one track to another. The data used by a text search engine is typically stored in what's called an "inverted word index". To index a large document containing a few hundred distinct words requires storing data in a few hundred distinct locations in the index files. (The problem becomes even worse for phrase-based indexing.) With mechanical disk drives, even with advanced caching and clever programming, a lot of seeks are needed to get the read/write heads to where the data resides. Google's web search, for example, solves this problem by storing their indexes in RAM, in huge arrays of machines with large amounts of memory installed. That's not practical for smaller-scale systems.
In fact it has been true for some time that on a typical server the CPU is no longer the gating factor in the speed of the machine. Millisecond seek times are more critical to performance than GHz of processor speed. Solid-state disks have the potential to speed up computers mostly because they don't require extra time for disk head movement when data is scattered across the media. Because of that, we should expect to see the cost of high-performance enterprise search systems come down, and their performance increase, over the next few years as the technology improves.
Is it perfect? Not yet. Yes, the costs of drives using the current generation of Flash technology will come down, and that will improve performance for management of large relatively static document collections. But flash SSDs still suffer from a limitation: a given block of data can only be written about a million times before that part of the drive won't take data any more. When that limitation is eliminated by the next technological leap, we can start using the drives for storing actual relational database information: and then we'll have a revolution in IT in general.
And it's coming none too soon. As the acceleration of the eDiscovery business continues, and as more and more data becomes subject to discovery in civil litigation, the industry will need every new advancement it can find just to keep pace.
Posted by Andrew Forber
Posted by Rande Simpson on Tue, Dec 22, 2009 @ 10:58 AM
Sharing Pictures Today is Just So Easy. Here’s some perspective...
I have fairly recently submerged myself in social media - Facebook, Twitter, reading lots of blogs, etc., and I can't help but think, every time I click on a photo link, about how much easier it is today to send or share photographs with people than it was 20 years ago before the public Internet and before digital data transmissions. I do not feel I am very old, but I guess I have seen some pretty big changes.
During the years I worked as a photo editor with the Associated Press in Washington, DC, I had the privilege to make several trips to Cuba with staff photographer Charles Tasnadi, one of the finest human beings in the business. Charles had known Fidel Castro as a revolutionary, and was one of very few US-based journalists allowed close access to him. Traveling in the 80's to Cuba required chartering a small plane from Miami to Havana, loading up about 7 cases of equipment containing photographic film and paper and the chemicals to process them, cameras, lenses, dryers, tanks, enlargers, trays, black plastic sheets, lots of duct tape, typewriter, a photo transmitter and lots of other miscellaneous stuff. After all, there were no spares available in Cuba!
The logistics about getting into Cuba is a whole other story: I will only mention that when we arrived at the Havana airport we were greeted by a soldier who watched the pilot open the door and spray bug repellant around the door opening. We were not allowed to exit the airplane until the Yankee bugs that hitched a ride were killed, presumably for fear of contaminating the purity of the Communist society!
Back to sharing pictures. After checking into the hotel room, the first thing we did was make the bathroom light tight so that we could process film and make prints, which we did by securing black plastic sheeting across the door with duct tape. We are not talking about a large bathroom suite: the enlarger usually had to balance on the toilet seat. Next the local phone company would come to the room and install a phone line that was supposed to allow us to have a clear line to transmit photos. You would pick up the phone and crank it and get the operator (I kid you not!).
Once film was hand processed in the tanks and dried, you had to use a loupe (magnifier) to look at the negatives and find the best images. A print was made, usually black and white first, and then a color version (remember this was done while on your knees in front of the toilet bowl). You typed out a caption on sticky backed paper and attached it to the print, then you wrapped the print around a rotating drum in the image transmitter, and then the fun began. You would crank the phone, get the operator and have her dial a number and beg her not to interrupt the line (more about this later). Someone in the New York AP office answered the phone and you explained you were in a hotel room in Cuba and you needed to send the photo right away.
If you were lucky back then a black-and-white photo was transmitted as an analog signal in 15 minutes, about 45 minutes for a color photo (these things take just seconds now in the digital world). But more often than not either the phone line would drop out at some point, or the operator would wonder why you were talking to the US for so long and would eavesdrop on the line to hear the conversation. In the analog transmission world of the 1980's you could not share data and voice: voice won and you would get nice lines of noise across the photo. So many times we would have to start the transmission all over, and I would spend hours trying to get out a single photo. The glamorous life of a globe-trotting photo editor! The good news was, once the photo was finally received in New York it would be relayed to essentially every newspaper around the world, and photos of Castro being so rare, it would likely be on the front page. That part felt good!
Now fast forward to 2009 and people and organizations share photos in a matter of seconds to any one around the world that has Internet. News photographers these days can preview the image and send it via Wi-Fi directly from the camera! Back then a photo agency would send at most 2-300 photos a day: nowadays they can send upwards of 6,000 new images on a busy news day, and our Merlin digital asset management customers typically store millions of digital photos from places all over the world.
I am sure most people have no idea how difficult it was 20 years ago to share just a single photo. Oh and in case you were wondering, duct tape does remove paint around bathroom doors, and photo chemistry can destroy waxed floors (we were always paying for repairs to the hotel rooms!).
Posted by Rande Simpson