Note: Now that ACDSee has added a Lightroom conversion utility, conversions to ACDSee from Lr are much easier to deal with. As a result, this article may be a bit dated! Progress and technology marches on!
A person posted in the ACDSee User's forum asking about converting from Lightroom to ACDSee Pro or ACDSee Ultimate. I responded to him how I went about changing over from Lr to ACDSee. While I have added some changes and clarifications to the original post, the heart of this post essentially is my reply to him.
I thought this might be useful to a wider audience, not only because there is a growing awareness of ACDSee products as a serious alternative to Lightroom, but because there is a lot of confusion as to what a photographic database is, and what it does.
I converted from Lightroom to ACDSee Pro in . . . late 2012, if I recall. There are no utilities to export the Lightroom database to ACDSee Database that I know of. It has to be done manually. You need to remember that the Lightroom settings are proprietary to Lightroom. No one just has the right to make a commercial product to go in and use that information. So the conversion isn't EASY, but if it is planned out and done systematically, it is do-able and worth the effort in my mind.
However you DON'T really NEED to convert your existing photos to ACDSee, You could just keep Lr around for the old photos and use ACDSee for the new. A lot of people work that way. I chose to do a full conversion.
In a fit of full disclosure, I am a retired Teradata DBA, This is pretty much how I would handle any database migration not just a photographic database. The exact details might differ from job to job, but the broad strokes remain the same.
But before I get into the conversion process, I'd like to explain some important background information some of you might want or need to know about.
Why Is There a Database In The First Place?
Quite a few people are confused about photo organization. If I have my photos stored safely on my computer hard drive why do I need a database? And why do even pretty simple photo Browsers/Organizers.have at least some sort of database function?
Finding photos
Many people tend to place their photos in folders that are organized into some sort of structure. Sometimes it is by year or date the photos were taken, sometimes it is by event or a person's name or relationship to the photographer. Whatever the logic the photographer used, this folder structure is very useful in finding those photos taken at the the last Family reunion or of photos of Aunt Sally before she passed away.
But what if you are looking for that photo of cousin Fred drinking from the gravy bowl at Christmas some time in the 1990s? or that photo of Grandma with Aunt Sally together after not speaking for 20 years? What if you wanted to know which photos were taken with electronic flash, or which photos were submitted to a photo contest? Or which photos actually won a contest?
This is where a database that links a specific photo to information describing that photo comes in handy. By typing in a few search criteria, it is much easier to find those specific photos. A database is that container for those search criteria.
I won't go into great detail, so the following description is very broad in its scope. But basically how NDE works is that when you display an image in a Non Destructive Editor (Like Lightroom or ACDSee Pro and Ultimate), what you see isn't the photo file itself, but an image read from your hard drive and then stored in your computer's short term memory.
Then, when you make changes to a photo, what happens is that the changes you make occur to the short term memory version and not to the image stored on your hard drive. This is also exactly what happens in a traditional "destructive" editing process, but if you want to make the changes permanent, You then need to save the version in short term memory to the Hard drive with the same name as the photo you originally read.
But with NDE, the changes you make are not only made to the displayed image in Short term memory, but descriptions of those changes are stored the database as well. When you are done, you have two choices, you can save the displayed image to a new file name and make the changes permanent like in any editor, or, you can just close that displayed image, essentially throwing it away.
That's OK, because the changes you made are stored in the database, and anytime you want to see your photo as you edited it, you can call up the stored, unchanged image, and your NDE program is smart enough to find the stored edits in the database and apply them to the stored image. It actually reconstructs your edited image on the fly.
This is really useful in that you can keep the original unchanged but can make as many different ways of editing a photo that you like, and then select the one you like best. Or, select them all!
And those controls that are in both don't often work the same way. Sometimes, the default position in one program's control is zero and that is in the middle of a sliding scale that might range from -200 to +200, while the control in the other program might also default to zero, but on that scale, zero is all the way to the left and the default slides from zero on the left to +100 on the right.
Even though those controls are named the same thing, can we be certain they are doing the EXACT same thing? How can we be certain that a control set to +25 in one control renders the same change as a +25 in the similarly named control in the other program? Changing from one program to another can be a bit of a problem for even the most experienced photographer.
And how does one deal with controls that are in the source program (The program you are leaving) but not in the destination program (The program you are migrating to)? Is there a combination of different controls that will do the same thing? Are there several combinations of different controls that could do the same thing? If so, which combination is the best? And will this one combination always be best for all different types of photos?
A lot of research needs to go into an automated conversion design before programming can even begin!
This can complicate things considerably when you want to export data from one database owned by company "A" to another database owned by company "B" As a retired Database administrator I can't begin to tell you how often I have experienced and heard about how a database conversion can be slowed and complicated by a company that simply refuses to believe that you can be lost as a customer!
There is no economic incentive for the company losing you as a customer to make it easy for you to migrate your data to a competitor. Fortunately, there isn't this level of pettiness in the photographic software industry, but on the other hand, there isn't much in the way of conversion utilities available either.
So just about any move from one program to another will require a manual conversion. It won't hurt to check to see if there IS a conversion utility going from the program you are leaving, to the program you want to go to, but you need to understand that it is unlikely you will find a program to do that for you.
Also Please remember: This only LOOKS complicated because I tried to write the steps down with as much detail as possible. Don't let my compulsive attention to detail scare you off. It isn't as difficult as it might seem.
Also don't think you have to do this in a day! These are old photos, You can take as much time as you want to get them imported into ACDSee! Also don't forget as I said above, you don't have to make the conversion if you don't want to.
But what if you are looking for that photo of cousin Fred drinking from the gravy bowl at Christmas some time in the 1990s? or that photo of Grandma with Aunt Sally together after not speaking for 20 years? What if you wanted to know which photos were taken with electronic flash, or which photos were submitted to a photo contest? Or which photos actually won a contest?
This is where a database that links a specific photo to information describing that photo comes in handy. By typing in a few search criteria, it is much easier to find those specific photos. A database is that container for those search criteria.
Non Destructive Editing
The advent of the concept of non destructive editing requires a place to store those editing changes. For those who don't recognize this term. Non Destructive Editing (NDE) is different from conventional photo editing. It is most commonly used in raw development, but can also be used for typical jpgs, tifs, and other image types as well.I won't go into great detail, so the following description is very broad in its scope. But basically how NDE works is that when you display an image in a Non Destructive Editor (Like Lightroom or ACDSee Pro and Ultimate), what you see isn't the photo file itself, but an image read from your hard drive and then stored in your computer's short term memory.
Then, when you make changes to a photo, what happens is that the changes you make occur to the short term memory version and not to the image stored on your hard drive. This is also exactly what happens in a traditional "destructive" editing process, but if you want to make the changes permanent, You then need to save the version in short term memory to the Hard drive with the same name as the photo you originally read.
But with NDE, the changes you make are not only made to the displayed image in Short term memory, but descriptions of those changes are stored the database as well. When you are done, you have two choices, you can save the displayed image to a new file name and make the changes permanent like in any editor, or, you can just close that displayed image, essentially throwing it away.
That's OK, because the changes you made are stored in the database, and anytime you want to see your photo as you edited it, you can call up the stored, unchanged image, and your NDE program is smart enough to find the stored edits in the database and apply them to the stored image. It actually reconstructs your edited image on the fly.
This is really useful in that you can keep the original unchanged but can make as many different ways of editing a photo that you like, and then select the one you like best. Or, select them all!
And All This Is Stored In The Database!
But this advantage is also a bit of a problem. Nothing is perfect and most NDE programs prove it!Every NDE program is different!
If you compare Lightroom to ACDSee Pro, you will see that they don't look anything alike. Most controls are different, and there are some controls in one program that simply aren't in the other program.
And those controls that are in both don't often work the same way. Sometimes, the default position in one program's control is zero and that is in the middle of a sliding scale that might range from -200 to +200, while the control in the other program might also default to zero, but on that scale, zero is all the way to the left and the default slides from zero on the left to +100 on the right.
Even though those controls are named the same thing, can we be certain they are doing the EXACT same thing? How can we be certain that a control set to +25 in one control renders the same change as a +25 in the similarly named control in the other program? Changing from one program to another can be a bit of a problem for even the most experienced photographer.
And how does one deal with controls that are in the source program (The program you are leaving) but not in the destination program (The program you are migrating to)? Is there a combination of different controls that will do the same thing? Are there several combinations of different controls that could do the same thing? If so, which combination is the best? And will this one combination always be best for all different types of photos?
A lot of research needs to go into an automated conversion design before programming can even begin!
Legal Protections
Then too, those programs are protected by copyright laws. While the raw, tif and jpg file formats are open to all, and the various components of those files are available for anyone to use; and while the information stored in those programs databases is usually considered your property; exactly HOW those components are used and encoded into the database are often copyrighted by the software publisher. In other words, you may own the data stored in the database, but the methodology in how that information is stored is owned by the software publisher.This can complicate things considerably when you want to export data from one database owned by company "A" to another database owned by company "B" As a retired Database administrator I can't begin to tell you how often I have experienced and heard about how a database conversion can be slowed and complicated by a company that simply refuses to believe that you can be lost as a customer!
There is no economic incentive for the company losing you as a customer to make it easy for you to migrate your data to a competitor. Fortunately, there isn't this level of pettiness in the photographic software industry, but on the other hand, there isn't much in the way of conversion utilities available either.
So just about any move from one program to another will require a manual conversion. It won't hurt to check to see if there IS a conversion utility going from the program you are leaving, to the program you want to go to, but you need to understand that it is unlikely you will find a program to do that for you.
Making the Conversion from Lightroom to ACDSee
While my descriptions use Lightroom and ACDSee as the source and destination programs, these steps are pretty much universal regardless of the programs being discussed.Also Please remember: This only LOOKS complicated because I tried to write the steps down with as much detail as possible. Don't let my compulsive attention to detail scare you off. It isn't as difficult as it might seem.
Also don't think you have to do this in a day! These are old photos, You can take as much time as you want to get them imported into ACDSee! Also don't forget as I said above, you don't have to make the conversion if you don't want to.
You CAN decide to keep Lightroom around for your old photos and just use ACDSee Pro or Ultimate for the new photos. That is a valid choice, though there is some risk in that decision as well. (for instance, what would you do if your old copy of Lightroom simply wouldn't work on the latest version of of your computer's Operating system?)
This is how I did it.
- Take your time, do it right, and don't take any shortcuts. If you don't have time to do it right, you probably don't have time to do it over either.
- Set a point forward date. Any photo created after that date will ONLY be handled by ACDSee. DO NOT let yourself backslide on this. That will only cause sloppy and time wasting extra work for you.
- BACK UP EVERYTHING in Lightroom not just the database, but the actual photos as well. I always found Lr's backup routine a bit misleading. It reminds you to back up the database but forgets to tell you to back up the actual photos as well.
- Embed as much of the database data into the photos themselves. Lightroom and ACDSee both have utilities to do this. IF your RAW, tif and Jpg images can store certain data within the file format itself, it is always smart to store it there. You can also store it in their respective databases engines for faster searching, but there is nothing like having most of that info built right into the photo itself. If you have several thousand photos stored in Lr, this could take a while Lr isn't the fastest photo db in existence.
- Take another backup of everything. Yes you just did it, but if you recall, you have just modified the file formats of each photo. But considering how much work that represents, don't be stingy.
- Lightroom's development settings are meaningless to ACDSee and any other Lightroom competitor, so any raw photo that is developed and not converted to tif or jpgs needs to be converted to one of those formats, exported from Lr and imported into ACDSee. I personally prefer tif files for many reasons but jpg will work.
- I exported the lightroom database text information into a spreadsheet format. Just in case. I'm not a heavy database user so I didn't have much that wouldn't fit into the photos embed process, but I did it just in case I needed it.
- This can be very time consuming depending on the number of photos you have. I suggest trying to split the work up into logical increments of work. In my case I broke it up into month and year. I had 10 years of photos to move to ACDSee, and from about 2008 on, they were mostly developed raw images.
- I exported the jpg images from 2003 to 2008 into 7 export batches, one batch for each year,
- Then I imported each batch into ACDSee individually,
- I checked the first few batches closely for accuracy and to make sure I hadn't screwed up in some way. After I was comfortable with the process I didn't check so closely. If I had text data I needed to add to the ACDSee DB, I did it here.
- For 2008 foreward, I had a 3 step process
- a conversion batch from Raw to tif
- If you want, you can export the raw images as well, ACDSee can handle them quite readily, but they will look like they did BEFORE you started editing them in Lr. That is why you need to export to tif or jpg with edits. Otherwise you will lose those legacy edits.
- Create an export batch from Lr
- Create an import batch to ACDSee
- Again the first few batches were checked closely for accuracy.
- AS a former DBA it was in my nature to worry about disaster recovery so once I started adding stuff to ACDSee database I started doing backups there as well. They can always be deleted once they are no longer necessary. But they do add peace of mind during transition.
If you plan your steps out and then follow that plan, a conversion to ACDSee isn't difficult, though I admit it can be time consuming. Also remember that there is no rule that says you have to perform the conversion in a single day, or a week, or a month. The conversion is for your older photos, if the actual conversion takes a year is anything really harmed by that? Not for most people!
Good luck and have fun (otherwise, what's the point?)