Monday, March 23, 2015

Converting From Lightroom To ACDSee Pro Or ACDSee Ultimate

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.

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.

  1. 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.
  2. 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.
  3. 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.
  4. 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.
  5. 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.
  6. 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.
    1. 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.
  7. 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.
    1. I exported the jpg images from 2003 to 2008 into 7 export batches, one batch for each year,
    2. Then I imported each batch into ACDSee individually,
    3. 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.
  8. For 2008 foreward, I had a 3 step process
    1. a conversion batch from Raw to tif
    2. 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.
    3. Create an export batch from Lr
    4. Create an import batch to ACDSee
    5. Again the first few batches were checked closely for accuracy.
  9. 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.
I kept the Lr database and Lr itself around for about 6 months after my full conversion just in case. After that, I realized I wasn't using it any more and got rid of it.

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?)


  1. Great description Glen. I particularly agree with storing as much photo data within the photo itself. This could preserve family photos for future generations (assuming TIF/JPG remains active -- while databases come and go)
    BertIverson of DPR

  2. Personally, I suspect 'cultural inertia' will keep TIF/JPG as a viable and usable photo file format for a very long time. There's a LOT of jpg images out there, and probably quite a few tifs, as well!

  3. Yes that does seem a lot of work. I am wondering whether a conversion to .dng before import to ACDSee would do the trick as. .dng is meant to be a universal format which should broadly translate to any program. Or would you say that the settings baked into .dng are the same as those in separate car files -only readable by Lightroom? I could put up with same variation as I am currently thinking updating some images to my current processing style via using presets.

  4. Unfortunately, converting to DNG won't help with the conversion. While the dng format is free for anyone to use, HOW the various photo packages store their information in the dng file itself is proprietary. If you re-read the above article, particularly the sections titled, "Every NDE program is Different", and "Legal Protections". This applies to DNG as it does to every other raw format. and DNG is really just another raw format. In fact Leica and Pentax both use DNG as their native raw format. At least, they used to.

    What that means is NO ONE can legally read the development parameters Adobe stores in the DNG file (or in their database either, for that matter). and even if they could, the parameters would not make sense to the non Adobe software. There are just too many differences in how each program does things.

    1. One last thing: ACDSee and most of the other non Adobe software packages READ DNG just fine, however since they can't make use of the proprietary Development instructions that Adobe stores there, any DNG files will appear as they originally did before being imported into Lightroom. However once you develop the DNG in the new software, it will look the way you have developed it.

  5. You speak of a lightroom conversion utility but ACDSee does not mention it on their website and I cannot find much on it. Can you point me to a place where I can read up on it, how it works, and what it does?

  6. Sorry for the late reply, I just noticed this pending comment.

    I have never used the Lr Conversion utility since I did a manual conversion before this was released. It can be found in the "Tools|Database|Import|Lightroom database" menu selection.

    Basically, it is a metadata conversion utility, it does not import your edits. You will need to convert the edited photos to Tif or jpg images.

    As far as I know, it does not destroy your old Lightroom database. It is pretty self explanatory, in that you point to the location of the database, and tell it to import.

  7. Hi Glen,
    Thanks for this thorough explanation of migrating from LR to ACDSee.
    I have all my images stored in a YYYY/MM/DD FOLDER format which is created on importing into LR. I also rename the files into a yyyymmdd—unique sequential index number format. So my two questions are. So I have a mixture of raw files, and jpegs exported from developed raw files in the same folder.
    1. Can I leave my images where they are and just import them into ACDSee after writing metadata to files?
    2. Can ACDSee ultimate import, move and rename files into my preferred structure or do I have to use Bridge to do this?

    1. RMWD - re Q1 yes, you can leave them in place. Your storage method resembles mine.

      RE Q2 Yes, I do it all the time.

  8. Hi Glen,
    I am thinking about moving over to Ultimate 2019 from LR 6.14 and have been looking all over the web at reviews about it and you seem to provide the most detailed information. The info that you have provided out on DP Review and here is wonderful information. My big question at the moment - you reference exporting all LR photos into TIFF format. I have about 114K photos and when I exported one photo in TIFF format at 300ppi the file size jumped from about 29MB to 113MB. In other words, my storage will go from about 2TB to 7.5TB. Is my thinking correct or am I missing something? That just seems like a huge jump.

    As a note, I had also been looking at ON1 Photo RAW because they advertised an AI conversion tool to convert LR edits to the ON1 PR database. That did not work our very well for me so I am looking at ACDSee again.


    1. Art, Thanks for the kind words. But I have no experience with LR6, so I'm not sure I know why Lr is creating such huge files, or just how large exported Tif files from Lr6 should be.

      However Tiff files ARE frequently much larger than their their equivalent raw and jpg counterparts. The only files I converted to tiff were the 'done' raw images (That is those that were 'done' and not already stored as a tiff or jpg in done status) Those other file formats I just imported into ACDSee directly.

      ACDSee will import your raw files quite easily, but ONLY as they looked coming from the camera. Any changes you made to them via Lr and stored those changes in the sidecar file, can not be translated into the ACDSee format.

      I recommend Tif file exports for 'done' raws because the TIF exports DO include the changes when Lr exports them, and Tif files are a lossless format generally of higher quality than jpgs.

      I would NOT export unprocessed raw, jpgs, Png, or any other file format to Tiff, JUST those raw images you consider 'done'.

      If jpg quality is acceptable to you, it is perfectly OK to export them as JPG files. That should result in a much lower disk usage. But as I said previously, the unprocessed raw files should NOT be exported. Instead just import the raw files directly into ACDSee.

      I hope this helps.

    2. Thanks, Glen. Very good points. You have made it very obvious that I need to do a lot more culling of my photos from past years. Many of my photos were imported into LR with presets so things could get interesting. But, as you have said, there is no hurry when working with old photos. I do have all the time in the world at this point.

      I am sure we will be talking in the future. :-)