Skip to main content

⚠️ Please note that this topic or post has been archived. The information contained here may no longer be accurate or up-to-date. ⚠️

Catalog bugs and performance problems

lewisl
I recently made a commitment to C1 and purchased it. I started putting new work into a catalog and left my LR catalog in place. I went on a trip and shot 1300 or so pics that went into about 9 sessions. Most of the work to cull and edit was done during the trip. The session folders were on an external SSD so it was easy to import images with adjustments into the new catalog back home. I'd used the location metadata field for the subject matter--easy to copy across all of the images in a folder. Using tokens, it was easy to use the import to generate a hierarchy of folders that fit the structure of the referenced image catalog. I thought I'd found it.

I decided to transfer the LR catalog to C1. Copied everything from the main machine internal drive to an external ssd. Relocating in LR--well I looked away from the screen for a second and didn't know it had even completed. I later had to do the same thing in C1: more than 1/2 of an hour. Did a little bit of clean up on the LR catalog: creating static albums out of smart albums and deleting a few unnecessary albums. I should have purged many keywords, but I didn't realize what a problem that would be. Now I have a nice LR catalog pointing at referenced images on an ssd.

I began to import the catalog into Capture One. I didn't expect perfect fidelity. Ratings and crops were enough--anything more is a bonus. At first, the process went really fast. Images were ticking off at a rate of 6-8 a second. It looked like it would take only around 3 hours. Well, then it started bogging down. Memory use of C1 is about 24G on an 8G machine. Of course, C1 doesn't get all 8 to itself. It probably only gets 4-6G physical memory. So that is 5 to 4 times overcommit of virtual memory. What the C1 code thinks it is doing in memory it is actually doing my swapping from disk to memory with millions, yes millions of page faults. And then there is the process of finding keywords in a newly imported image and verifying against all of the existing keywords. By the end the process was taking 2 seconds per image. In the end it took over 14 hours. I know; I did it twice.

Problems:
Some images result in 4 variants per image. Huh? I checked the LR catalog to see if I had virtual copies for those images? Yes. Turns out you can quickly filter for virtual copies in LR but you cannot filter for non-primary variants in C1. So, I had 1289 virtual copies (not counting the primary) in LR. These were tripled to be nearly 3900 in C1. Since there is no search, I had to visually scan for the multiple variants icon, select the non-primary variants, and delete them. Painful. This is obviously a bug.

Horrible bug in relocate. So, the reason I did this twice in C1 is because it didn't work the first time. What I thought I could do was just import the Lightroom catalog and then relocate to the copied folders on the SSD. Ha Ha. Now, C1 developers will not consider this a bug but it is. Folders in a C1 catalog are just another collection--there is nothing special about them. Seems clever, but folders are special: they are the physical organization. Here is the problem. Let's say you pick a year/month folder that contains say 6 sub-folders. You "locate..." the year/month folder. It is found and moves under its appropriate parent folder. But the 6 sub-folders DO NOT. This is not a recursive process! Never mind it costs me some work to go through and locate... all 1200 or so folders individually. The bug is that the referential integrity of the database has been violated--it's in an inconsistent state--a big NO-NO. A parent folder on physical volume A shows that it has children sub-folders on physical drive B. C1 Devs: tell me that this is a valid consequence of implementing folders as collections. Big bug. So, part way through I stopped. Relocated the ENTIRE LR catalog just via the single top level--the whole relocate was recursive. Then, I imported this LR catalog for a second pass.

Now I finally have a C1 folder with about 3900 too many variants. Let's poke around a bit and see if everything came over more or less ok. The good news is that basic metadata comes over fine: IPTC, exif, ratings, keywords. Cropping. Awesome. Exposure and other basic edits--not clear. I can deal. But, there is a problem: I want to look at what's in 2009 09 / foo. Oops, where is it. The folder hierarchy is in essentially random order. This is a bug.

Lets sort it. Sort by name. On the SSD it takes over 40 minutes. Seriously? There are 140 2nd level folders (one below the root). And roughly 8-12 subfolders each on average. Something like 1200 to 1680 folders. 40 minutes to sort? Seriously sorting a folder list to display in the UI is NOT a physical task. Nothing is moved on disk. No OS directory is being changed. It is just a list to aid command dispatch in the UI of the product. But, because folders are collections nearly every image's metadata has to be touched to update the collections the image is member of. Poor performance based on poor architectural decision.

here is the bug: sort it once. Do some viewing. Import something new. The display order in the library tab goes random again. 40 minutes to sort it. This is a just a bug.

Add new folders (Add new folder... command). The folders don't go into the sorted order. They go at the bottom. Bad design decision. Guys: sorting in the UI is a display trick; it's not physical. You are sorting a tiny amount of data in memory, putting it into your data structures for UI display, re-displaying part of the UI. Those locations in the library tab reference a data structure which does contain the actual folder (or collection) so that the command can trigger a query and then display the results. But, just generating a sorted list is trivial.

Deleting keywords is incredibly slow. I should have cleaned up in LR first. But, the problem here is that when a keyword is deleted, any use of it (reference by an image) has to be removed from said images. With proper way 2 way join tables this should be very fast. It could take over 10 minutes for the C1 UI to be active again. I did go back to LR and do the clean up just to see how long it takes and I deleted some of the messy keywords. Instant.

Sync'ing a folder containing images is not recursive. I can't tell whether it is or is not in LR. But, in C1 there is a checkbox for "known folders". Of course, the known folders might be out of order. What's clear is that checking the box does NOT sync the subfolders. The immediate subfolders do come in, but not their children or images. Call this a UI error. The label for the check box is a bit misleading. It would be nice if the checkbox made the command fully recursive.

Applying to new keywords to an image took 5 to 10 minutes.

Deselect all would leave the solid white outline around select images even though the deselect all command became grayed out (as if it had been done). This is a consequence of slowness--the UI was not being refreshed. Better to address the architectural causes of slowness than to fix the minor display bug.

Multiple selecting images (command click) can take over 5 seconds per image.

"Show in library" for an image does NOT show the folder when the starting point is the "all images" collection. Well, that is when you need this command--out of a sea of images you want to find where it is--if it is anywhere (it turns out an image can be removed from its folder collection and still remain in the all images collection--this is another referential integrity bug). It turns out that "show in finder" works and works as fast as you'd expect--not quite instant.

Show/hide folder hierarchy command occasionally became inoperable. Not clear why. Changing command tabs did not "clear" it. Quitting and restarting C1 did get it back to normal.

A few bugs, but the big problem is poor--desparately poor performance--cause by poor schema design of the database, poor catalog architecture, and nearly non-existent memory management. Thrashing to disk with overcommitted virtual memory use will kill any app. Virtual memory is not magic: it is writing over-committed memory to disk and then retrieving it later. When this is used for less frequent actions (context switching between apps; loading a new file, etc) it's handy and not too agonizing. But, when it happens for highly frequent activities then an app grinds to a near halt. This is what happens to C1. I am sure the Devs will say, just get more RAM. Sure. The listed system requirements are 4G. That is surely unacceptable. At 8G with a Core I7 3.2gz processor I would not expect grinding slowness. Indeed, LR does all of the equivalent database-related and ingestion operations MUCH faster (it does do some things more slowly than C1). I would certainly expect my 8G machine to be slower than a 24G machine. But, slower, not blocked.

These things happened. They are facts. Sorry to all of the apologists. There are problems. I hope I proved my bonafides with my intro. I invested a lot in learning C1. I had a very successful travel shoot experience using sessions, granted with only 1300 images. Importing the session images (via import image, NOT import session) with adjustments and generating a nice automatic folder structure as part of an existing catalog was flawless. The quality of the raw conversions was excellent. The streamlined, very predictable steps to use editing commands to achieve desired image results was VERY PLEASING--better results and a better process than LR. Highlights: spot editing with so many operations enabled, especially curves. Highlights and shadows controls work marvelously. Many people love color editing--didn't need for the travel shoot but I've used subsequently. Great. What is special about Capture One is that as manufacturers (well, designers) of a medium format digital back, these guys understand how a scene and its lighting stimulate an image sensor, generate electrical measurements, which are then interpreted and processed into an image. Since that rendering process involves converting direct physical measurements from the sensor into image data, they also really understand how to ALTER that process with intentional edits--and produce impressive results. I respect this and enjoy it. This is what captivates users (I think) about Capture One. Unfortunately, the tawdry details of software engineering--memory management, data structures, algorithms, coding decisions seem to be the step child of development. So, we are left with the impressive image processing capabilities embedded in a poorly performing outer package.

In the race to compete with Adobe and the opportunity to acquire disgruntled former Aperture users perhaps there has been some rampant "featuritis". It's all understandable. I'd like to suggest perhaps some breathing room for software quality. The product is sufficiently competitive with LR. I don't see many people begging for website generation or auto-printbook generation. (Nothing wrong with these things; sure some people like this stuff, but they are infrequently used and unlikely to be competitively essential.) A moratorium on new features for 12 to 18 months would be beneficial. Focus only on new cameras (gotta do it), bugs, and architectural retooling for reliability and performance. The latter is difficult and risky work. Admitting the need for this would not be a marketing negative. It would earn trust and gain more users. The 12 to 18 months should not be done in one big bite. Better to have several releases with some work requiring a long effort and other work that can be released incrementally.

I am going to try to figure out how to get C1 working with Photo Supreme. There are some problems: crops don't show up. The process is quick, but less than ideal. I want to get to a global catalog solution. Not everyone agrees. I love using sessions for the initial pass of the work. It is reasonable for me to not have a single catalog--global really just means big--say all the images of family over the years. Other catalogs can cover other subject matters. I do not what all my images split across 200 or more sessions--I want searching across a larger span to work well. This is what I mean by "global": pretty big, which ought to mean 50,000 to 100,000 images per catalog with good performance, no hangs, no multi-minute UI hangs. I think it's possible.
0

Comments

49 comments

Date Votes
  • lewisl
    So, here is the continuation of the saga. There are two messages:
    - the first--this one--shows how truly bad the catalog and keyword capability is with some factual evidence.
    - the second is much more positive: there is a very satisfactory way to use Capture One for non-destructive editing in conjunction with another image manager, using sessions. I tried an experiment with "megasession," which didn't quite work but someone else might give it a shot. Finally, I am just using the open session trick that so many users have decided is the preferred way. I'll describe where I came out in a usable solution in the final message.

    The sorry saga continues...

    A post in this thread suggested that it would be better to import images into a new catalog rather than using the import catalog (from LightRoom) feature. This seemed reasonsable so I tried it by importing from file, and leaving images in current location.

    I have all of the images on a USB 3, SSD, organized, for example, as /Pictures/2015 04/Florida Trip. There are approximate 640 folders and 74,286 files. After 2 minutes to determine which files to import the tally was 52,470. I started at 6PM.

    The big problem is that as C1 imports it rapidly bogs down and takes a longer time per image:
    - at the very start, 50 images / sec.
    - after a few hundred images, down to 7 / sec.==>this is appromately 1/5 the speed of Lightroom (LR)
    - after 4100 images imported C1 reported "about an hour left"--which would turn out to be a joke
    - at about 12,200 images imported, C1 reported about 2 hours left. But, it was importing 2.2 / sec--a considerable slow down. Just using math there were another 305 minutes to go--over 5 hours--and given the progressive slowdown in throughput it was obvious this was going to take longer.
    - at 15,000 images imported C1 reported "about 3 hours left"
    - at 26,980 images imported at 9:22PM (3 hours 20 min.) C1 reported "about 3 hours left"--this would mean the job would take over 6 hours. We have 25,490 images to go and C1 throughput has dropped to 1 image / sec. So, the math says that is over 7 hours remaining--not what C1 was reporting. Plus the time already elapsed, we'd be at over 10 hours.
    - at 11:25PM 33,369 images had been imported and C1 reported "about 3 hours left". C1 throughput had declined to about .4 images / sec. So, it had been 5 hours and 25 minutes with 19101 images left to import. At this throughput, that would be more than 13 hours more--a predicted total of over 18 hours. But, we should assume more progressive slowdown in throughput.
    - So I stopped it using "cancel" in the dialog box. C1 reported "The import completed successfully." It took 3 minutes of spinning beach ball to settle down. Next click on the UI of C1 led to the spinning beachball, which did not stop. CPU was at 238%--using more than 2 cores. RAM was at 22G, which means that C1 was probably 4x overcommitted on virtual memory--no wonder it is slow. What C1 code (and developers) think is happening in RAM is really happening on disk. Memory continued increasing.
    - Time to force quit. (Sometimes C1 and the catalog recover successfully from force quit and sometimes not... It is not expected that an app will always be able to recover--it depends where the app is in its processing and what has already been committed to disk.)

    So, at this point I give up. Before we go on and try to understand what was happening, let's consider a comparison:

    Lightroom imported the whole thing in under 30 minutes.

    That's right. The import was over; all thumbnails were generated (or imported); I could view all images and scroll the thumbnails; the UI was responsive. All keywords were loaded and could be used to filter images. The previews were DEFINITELY NOT generated in Lightroom yet. This would go on for hours, but you can use the app, quit the app, and resume generating previews the next time.

    So 18 hours (with no assurance of completion) vs. 1/2 hour. Capture One image import to catalog is 36 times slower or Lightroom completes the task in 3% of Capture One's time. Don't have to love Lightroom. This is just a fact importing the exact same images from the same SSD on the same computer.

    Interpretation
    What's going on here?

    1. Capture One memory management is basically incompetent. You can't overcommit virtual memory that much. Even though the OS will report to the app that it can get more memory, it's virtual memory--it's disk. The app has to do its own memory management and use only physical memory. No automatic garbage collection for an app like this; developers have to allocate and release memory in code.
    2. Keyword accumulation kills C1. The images had lots of keywords. Each time an image manager imports an image, it has to look at whether the image contains any keywords. If so, it then has to look at the catalog: is the keyword already present; if so, add the reference to the keyword to the image record. If not, add the keyword to the catalog and then add the reference to the image record (in the catalog db). As the number of keywords increases, the time to search though the existing keywords goes up. *But, it should not.* C1 could use a hashtable for the existing keywords--the time to find a match (or no match) is CONSTANT--it doesn't matter how many existing keywords there are already. Or, they could create a temporary table in sqlite and sqlite would effectively do this for them.
    3. Poor task queueing. You'll notice that Lightroom had not generated previews when it completed importing. Do one job before you start the next job. While you can sometimes have concurrent tasks (not referring to threads here--all modern apps use lots of concurrent threads) you have to be careful when there is resource contention--conflicting demands for the processor, for disk, and for comm (not applicable here), etc. The big limiting factor importing images is access to disk. One process wants to read and other processes want to write and access to disk becomes a bottleneck. Code has to carefully manage this and not start tasks that prevent existing tasks from completing or create more resource contention. This is close to a "deadly embrace."

    So, catalog creation, catalog management, and keywords are seriously broken in Capture One. There can't be any dispute of this fact. But, all is not lost--when you work in sessions you find that processing of individual images is NOT a problem. Capture One can import and render images quickly. It is the processing of the database of the catalog that kills Capture One.

    My wife asked me to explain this in a non-technical way:

    "So there is this house. It has the most fabulous kitchen: an incredible gas range and ovens; fabulous pots and pans; a great herb garden right outside; the best way to store ingredients to keep them fresh. You can cook the most amazing meals and be in love.

    The problem is with the rest of the house. The windows are broken. The doors hang askew off the hinges and bang in the wind. The roof leaks. The floors are a bit rotten and spongy when you walk on them. The beds have bugs. The walls have mice and rats crawling about.

    But, oh--the kitchen. If you want the most extraordinary culinary achievements you have to do it in the rotten house."

    That's Capture One. The kitchen is image processing and editing. The catalog is the house.

    Compared to Lightroom:

    "The house is well-built with industrial precision. Each wall meets each floor perfectly. You can put a right angle triangle in the corner and it fits perfectly. The windows are double-pane. The roof is new.

    But the kitchen just has a microwave and one of those glass top electric ranges. You can heat up frozen mac and cheese or boil up some Top Ramen. You might get enough calories to survive, but nutrients--not sure."

    With obvious hyperbole in both cases, Capture One has fabulous image processing and editing capabilities and Lightroom has better catalog management.
    0
  • lewisl
    Many people have suggested using some other application as the catalog, or digital asset manager, and Capture One as the raw processor--and, really, more than that--the image editor. Candidates most often mentioned for the catalog include Lightroom, Photo Supreme, or Photo Mechanic (not rightly a catalog, but nearly functionally equivalent). With minimal fuss, all can launch one or more images "into" a Capture One session. Use an "empty" session and close Capture One with your empty session active. The next time Capture One is asked to open an image, it will use the previous session.

    A session seems like another alternative for "storing" images, but really it is not. The images stay where they are. No import is necessary. Capture One pretty much immediately creates a Capture One folder structure in the containing folder of the image and puts its thumbs, proxies (previews), and adjustments in the Capture One folder. If you have Full Sync for metadata, then existing XMP sidecars will be read or new ones created. It doesn't matter what folder you start in: any folder you "touch" in the library tool can instantly be used to edit images with Capture One. The only thing that makes a folder a "member" of the session is to make a folder a "favorite" or to put images in the Capture or Selects folders. This is all very fast because: i) typically we are dealing with fewer images; ii) C1 doesn't have to deal with the catalog database--a session database holds records for "member" images including their location and metadata. It is really quite good. You can non-destructively edit Raw, JPEG, and TIFF files. Life is good.

    There are some problems working this way. These are not, strictly speaking Capture One's "fault". The same problems will occur if you are using DXO, Photo Ninja, Iridient, or any other raw processor. (I am not saying these products are all equivalent to Capture One or each other.) It turns out that Apple Aperture's innovation, later adopted by Adobe with Lightroom, of combining DAM with raw processing and non-destructive (or parametric) image editing was fundamental.

    Here are some of the gotchas when you view images processed with Capture One with an external cataloging app (from the perspective you get while in the cataloging app):

    1. Thumbnails won't look exactly like the edited images.

    2. Previews won't look exactly like the edited images, though cropping is likely to show.

    3. "Albums," "galleries," or other non-copying collections of images made in the cataloging app won't be available in C1 and collections in C1 won't be available in the cataloging app. This is especially important for photos you would like to collect together across different file system folders--indeed, a major benefit of collections.

    4. Metadata may or may not synchronize across images when viewed in the cataloging app and C1. Generally, with RAW you are likely to be in decent shape. Few raw processors write metadata updates into the raw files, giving you the option to use .xmp sidecar files. Cataloging apps generally can read and sync metadata with sidecar files. The problem is which metadata fields and how they are encoded. Color labels are a particular sore spot. Ratings and many IPTC descriptive fields are ok. But, collections (albums, galleries) aren't in this metadata. A bigger problem is with jpeg and tiff. C1 takes a very purist stance and never writes back to any files it processes. (I am not saying this is right or wrong or what you or I prefer.) Nearly every other app DOES update metadata in jpeg and tiff files. Both formats provide a reliable standard for doing so. So, Photo Mechanic, Photo Supreme, and Lightroom won't see C1's metadata changes to jpeg or tiff files. You might say, "who cares?" Well, I still shoot some photos in jpeg. Phone pictures are jpeg. I tend to shoot jpeg from the amazing Sony RX100. Non-destructive editing is very important for jpeg files because every save degrades the image. Tiff files are appropriate for edited output--you won't shoot tiff. But, it is reasonable to keep track of them. But, I do have a solution (below).

    So, how bad is this? Problems 1 and 2 aren't a big deal. Problems 3 and 4 are. Metadata and collections are how you really organize the images you care about.

    Collections are really important. If you have graduation photos and you want to share the best with other families--or the ones of their kids--you create a collection as the first step. Then, you can export to send or print. Using collections postpones the step when you make copies. The collection in Photo Supreme won't extend to images you've edited with C1. Turns out there is a reasonable workaround, but it depends on reliable metadata synchronization.

    So, the collection problem led me to consider "megasession." Why not make a single session that "held" every image? So, I set out to do this:
    1. Make a session.
    2. Click on a folder of images. Make it a favorite. Wait for generating previews and synchronizing metadata to settle down. Starting too many processes is a sure way to hose C1.
    3. Keeping going. With 640 or so folders it's a royal pain, but I don't have to do it all at one time. When I go back to a folder that's important, I can always add it.

    Why bother? you say. What's the advantage. Here's what you get:

    - you can create collections that contain images from any folder. (Good news--you can do this anyway.)
    - you can filter ALL of your images on any metadata criteria
    - you can process and export photos across folders based on collections or metadata

    Pretty awesome. So, off I went. The problem is that when I got over 5000 images as "members"--their containing folder had been made a session favorite, C1 started hanging on each additional folder. So, it seems like the session database (.cosessiondb) falls prey to some of the same limitations as catalogs.

    So, I gave up on "megasession." I wish "megasession" worked. Perhaps Phase One should defer re-engineering catalogs (not give up--just postpone) and just expand the database for sessions as a shortcut. For pulling in a lot of old images, touching and "favorite-ing" all the folders seems prohibitive, but as a going-forward solution it would be great--you've only got to do it for NEW images--and that will be just a few folders, if that, at a time.

    Here's a workable solution:
    I'll use something else as the cataloging app. I am here in the realm strictly of my personal preferences. You could get a slightly different solution to work for you. I've tried Photo Supreme, Photo Mechanic, FastRawViewer, and Lightroom. I already own Lightroom perpetual license ($149)--if you don't it might not be on your list. I've used Lightroom since version 1.1. I know it very well. YMMV.

    Preliminaries:

      - Photo Supreme seemed like it could do that job. I had used IdImager back in the days of Adobe Camera Raw, Photoshop and lots of tiff or psd files. But, it frequently hung trying to import. I could not get emails to go through or be replied by the developer. Probably, not his fault. Works for a lot of people. Not me.
      - Photo Mechanic is a bit confusing, but quite amazing for what it does. I opened folder and sub-folders for the ENTIRE DRIVE of 52,470 images and it generated the thumbs in like 3 minutes. I would never do that as a routine, but it worked. For a normal selection of folders, it is nearly instant. Because there is no catalog database, all connections between Photo Mechanic and C1 must be through sidecar files. There are no collections in Photo Mechanic. Metadata is powerful but a bit confusing. I am not a photo-journalist. This is the first time I discovered the problem that C1 puts jpeg metadata in a sidecar that Photo Mechanic, and other products, ignore. Photo Mechanic is a good product with its own learning curve.
      - FastRawViewer is a much simpler product. It is intended to be used as your first cull/review of a new batch of photos (either on the memory card or after copying to hard disk). You can also open any folder and see the images: jpegs and RAW (no tiff, no psd). Metadata is limited to ratings, color labels, title, and description. Cleverly, they have an option to display metadata for jpeg files that is loaded from sidecars. This hinted that I could solve the jpeg/tiff sidecar problem. FastRawViewer is a fine tool but too simple and not intended to solve a large image management task.
      - So, for me Lightroom was the answer. It's actually faster than Photo Supreme at importing all of the photos. It's keywords interface is unlovable for sure, but I am used to it. You can use the plug-in from John Beardsworth to "edit in" for raw or you can just reveal in finder and open in C1. I created a Keyboard Maestro macro that does it. Done.


    Here's the answer for me:

    1. Import from cards and import to hard disk (SSD) with LR.
    2. Rate, tag, add metadata, add keywords in LR.
    3. Edit all file types in Capture One using an "empty" session.

    Here is my solution for metadata sync'ing for jpeg and tiff files. This may be a "corner case"--something that barely matters--for you. For me, it means I have a more or less complete solution that can work for all of my old images (still need to do something for psd, but that is minor) and can support new images shot in jpeg.

    I wrote scripts in Python, using the Python XMP Toolkit, to "sync" metadata. pic_update_from_xmp.py reads metadata from the xmp sidecar and updates it in the image file (jpeg or tiff). So, I can work on photos in C1, change the ratings, and later see what I did in Lightroom. You may say, but didn't you do all the rating/culling already in LR? Well, that is another disadvantage of a 2 product workflow. You can rate to a 1st approximation using thumbnails or initial previews. But, then when you start working on say 3 versions of a similar shot, you really don't recognize the best shot until you've looked critically at focus, depth of field, subtle lighting differences--which are only things you notice when editing. So, I change ratings as I edit.

    xmp_update_from_pic.py goes the other way--from the image file (jpeg) to the xmp. So, the ratings and labeling I do in LR will be visble in Capture One.

    Right now the only metadata I am syncing includes rating, label, urgency, and category. I will certainly add title and description. Again, I am not a photo-journalist or professional photographer so I don't need a rich array of metadata. Which gets me to my solution for collections.

    The metadata field category is pretty ideal for collections. It is just a text field in the photoshop grouping of xmp fields. So, I can build a collection in EITHER Lightroom or Capture One. From the grid of images in the collection--let's say its "Grad 2016 Pics"--I just update the category field to "Grad 2016 Pics". Now, I can go update my metadata--an extra step (ugh), but it's quick; filter on category in the other product, and create the corresponding collection.

    It IS a disadvantage to use two products. Recall at the beginning I noted that Apple's innovation (later adopted by Adobe) was fundamental. I don't agree with the folks that say it is better to separate DAM from raw processing. Non-destructive editing has changed the fundamentals. We now want to avoid "freezing" changes into a tiff or jpeg rendering at all or until the last possible moment. It really does help if we can manage our images in the place we do the non-destructive editing. It's a disadvantage, but not impossible.

    Consider the NORMAL order of business rather than attempting to switch products for 18 years worth of images. In new work, some shoots are casual and you don't care except for an image or two. Adding the new stuff to your catalog is enough. Sometimes, you've got a more important shoot where you intend to do a lot of work. That will be less often (unless you are a pro) but the photos will likely be in a single folder. So, you sync metadata at the end of each working session.

    So, the end of the saga:

    I won't be frustrated any more. I can use Capture One to process raw and edit images. Or Lightroom. Or anything else. I have a reasonable solution for a useful subset of metadata. Life is good.

    Capture One will get around to fixing catalogs--or not, according to their own lights. Up to them, not us. It would be really good if they did; not even close to the end of the world if they don't.

    I've got a solution. Maybe you're already there. End of saga.
    0
  • EnderWiggins
    Lots of good points made by you.

    I think we can all agree that there seems to be some serious coding deficits on Phase Ones side when it comes to database design.

    But....

    [quote="lewisl" wrote:
    It turns out that Lightroom's innovation of combining DAM with raw processing and non-destructive (or parametric) image editing was fundamental.


    Sorry to nitpick here, but this credit has to go to Apple and the Aperture developers.

    Aperture was the tool that kicked off the combination of extensive DAM + non-destructive editing and treating a RAW file from your camera like a "digital negative", thus building the first true bridge from the analog era to the digital world.

    The 1.0 came out in October 2005 and sent shockwaves through Adobe HQ. Three months later Adobe hastily released a Lightroom beta, which was nothing else than a patched up combination of different pet projects inside the company. Thats why LR still feels so clunky with its forced modular approach, an idea which nobody would really come up with when designing it on a blank white paper.
    It was not until January 2007 when the beta program for LR was finally over, almost 1.5 years after Aperture.
    0
  • Eric Nepean
    [quote="EnderWiggins" wrote:
    Lots of good points made by you.

    I think we can all agree that there seems to be some serious coding deficits on Phase Ones side when it comes to database design.

    But....

    [quote="lewisl" wrote:
    It turns out that Lightroom's innovation of combining DAM with raw processing and non-destructive (or parametric) image editing was fundamental.


    Sorry to nitpick here, but this credit has to go to Apple and the Aperture developers.

    Aperture was the tool that kicked off the combination of extensive DAM + non-destructive editing and treating a RAW file from your camera like a "digital negative", thus building the first true bridge from the analog era to the digital world.

    The 1.0 came out in October 2005 and sent shockwaves through Adobe HQ. Three months later Adobe hastily released a Lightroom beta, which was nothing else than a patched up combination of different pet projects inside the company. Thats why LR still feels so clunky with its forced modular approach, an idea which nobody would really come up with when designing it on a blank white paper.
    It was not until January 2007 when the beta program for LR was finally over, almost 1.5 years after Aperture.


    Apple's implementation was very solid from day one - the Apple catalog browser performance and features in version 1.5 was superior to what Capture One has in versions 8 and 9.

    There are two big issues here. One is browser performance - speed of browsing large catologs and speed of importing , and the other is Quality.
    0
  • Peter Orczykowski
    I have gone through a similar process to end up where we all are - happy with image quality of C1 and unhappy with the catalogue performance. But your solution lewisl will not work for me. I understand that working pros need to produce a final image to meet a deadline and once this is done, there is no need to go back to it again. And C1 has been written largely for their clients and at 50K a pop for the camera kit you have few amateurs involved. Except now they want to be the solution for everyone, including masses of amateurs. I don't believe that I am that much different from the rest of amateur photographers for whom this is #1 hobby. And for me there is no final version of the image, I go back to older images and tweak them frequently enough. And for that you do need a software that is both DAM and image editor. Only that gives you a preview of your image as it is now. Aperture was certainly the most successful product in that category, shame on Apple for dumping it regardless of their changing priorities. And yes, Lightroom is a better DAM and C1 is a better image editor. I'll take image quality over DAM performance any time, so here I am.

    And when I get frustrated with C1 catalogue (often enough), I say to myself: "Remember days when you couldn't add a keyword to the image while in edit mode?" I rest my case. 😊
    0
  • lewisl
    Ender,
    I stand corrected. Thank you. Back in 2005 I was not a Mac user (am now) so I did not know very much about Aperture. I realize many people praise its design and lament its passing. Again, thanks.

    - Lewis
    0
  • lewisl
    Hey NNN...,
    Perhaps change your user name? It's ok by me if it is anonymous, just shorter.
    I, too, am an amateur photographer and go back to previous images. I certainly agree that integrated DAM, raw processor, non-destructive editor is fundamental and ideal. There is a workable one: Lightroom. On the other hand, if you prefer C1 image editing then that is not such a good choice. Why we are all here...
    There is yet another alternative that I did not describe. Though I really wish "megasession" could work, the primary benefit of megasession is the ability to filter ALL IMAGES--and that is a good benefit. But, if you could live without it you can still use an "empty" session to access all of your images. Just use the library tool and the hard disk folders to navigate to any photos. Naturally the Capture One folders retain everything you did with images and xmp sidecars will have most (all?) metadata that it is possible to edit with C1 (hierarchical keywords will get flattened and there are other keyword disadvantages--leave that to another post). Of course, this includes accurate thumbnails and previews.
    So, you can just reach and edit everything. I am not saying anything new here--many other users have pointed this out. When I first considered it, it seemed much too compromising. While the compromise is quite real, it is not as bad as I thought. Again--you lose the ability to search and filter on metadata across your entire body of photos--and that is a loss, to be sure.
    And this is where the separate DAM comes in--and also works with Photo Mechanic awkwardly. You CAN search and filter across metadata across all of your photos. Then, just "pop" into C1 to view accurate thumbs and previews. Since you can't view multiple folders in C1, you can temporarily favorite all of the folders that contain filtered images. You can also create a collection across images anywhere, even to folders that are not favorited. You can either retain these favorites or remove the folder from the session favorites. Up to several thousand images, there is no problem. It only seems to become a problem when you have thousands of images across favorite folders.

    I am not saying this is perfect. It is still a compromise. We wish catalogs in C1 worked adequately--what they have to day is NOT even remotely adequate--adequate is still remote for them, and then good and excellent still beckon. It's just not as bad as I originally thought.
    0
  • Eric Nepean
    [quote="NNN635397989495214331" wrote:
    I have gone through a similar process to end up where we all are - happy with image quality of C1 and unhappy with the catalogue performance. But your solution lewisl will not work for me. I understand that working pros need to produce a final image to meet a deadline and once this is done, there is no need to go back to it again. And C1 has been written largely for their clients and at 50K a pop for the camera kit you have few amateurs involved. Except now they want to be the solution for everyone, including masses of amateurs. I don't believe that I am that much different from the rest of amateur photographers for whom this is #1 hobby. And for me there is no final version of the image, I go back to older images and tweak them frequently enough. And for that you do need a software that is both DAM and image editor. Only that gives you a preview of your image as it is now. Aperture was certainly the most successful product in that category, shame on Apple for dumping it regardless of their changing priorities. And yes, Lightroom is a better DAM and C1 is a better image editor. I'll take image quality over DAM performance any time, so here I am.

    And when I get frustrated with C1 catalogue (often enough), I say to myself: "Remember days when you couldn't add a keyword to the image while in edit mode?" I rest my case. 😊


    I work for a very large SW company delivering Telecom equipment.

    We have a saying "You can test and find your SW bugs on our own equipment, or you can find them on your customer's equipment" In the second case, the customer bears the cost and the risk against her business and her data. And she will not be pleased.

    What we see here is that Phase One don't invest much in SW verification. Bugs are fixed and yet they still exist. Bugs from two releases ago reappear. Customers loose data, have crashes and spend endless time in troubleshooting. CUSTOMERS are trying to define reference configurations.

    SW verification requires hard thinking and commitment - you have to define equipment configurations, SW configurations, test cases, performance metrics and you need to take into account known bugs and features, and make updates for new features and new bugs. And you have to commit to fixing more bugs before release, because you will now find more, until you improve other development proceses.

    If a vendor has done that work, then immediately he can say what the reference configurations are and what the expected performance is. (Phase One has no information on this --> poor verification strategy)

    A very good strategy, which we have done with a very big improvement in quality, is to set up a Beta program with key customers, and we test our latest release with them, and find and fix those bugs before a general release. You can see that Microsoft and Apple does this as well, for example.

    In this way you don't have to buy the equipment, the configurations are realistic, but you still have to invest the time.

    I think Phase One's "unorganised Beta" will be over at about version 9.2.
    0
  • SFA
    Eric,

    Does your company operate in a corporate customer environment or with consumers in a fast changing environment - something like mobile phones for example?


    Grant
    0
  • Eric Nepean
    [quote="SFA" wrote:
    Eric,
    Does your company operate in a corporate customer environment or with consumers in a fast changing environment - something like mobile phones for example?
    Grant


    We operate in a fast changing competitive corporate customer environment closely related to mobile phones, similar to Nokia. There's considerable variation in installed equipment and tremendous pressure to upgrade features quickly. Customers get extremely annoyed and vocal when your latest SW upgrade causes them to have operational and business problems. It is a different business than supporting consumers directly, but many similarities as well.

    Hence, in my original posting I drew attention to methods also used by Apple and Microsoft, who support consumers directly. Adobe uses similar methods, I think.

    We also do a lot of in house testing, but those costs are manageable only when you have corporate customers, and hence I did not suggest that.
    0
  • EnderWiggins
    I've said it before and I'll say it again:

    viewtopic.php?f=61&t=22337&p=107689&sid=839450ef56eda3b756dc6d238c03b6ec#p107689

    Apple has 115.000 employees
    Adobe has 12.000
    Phase One has 400, 20 of them are working on C1
    0
  • Peter Orczykowski
    [quote="EnderWiggins" wrote:
    I've said it before and I'll say it again:

    viewtopic.php?f=61&t=22337&p=107689&sid=839450ef56eda3b756dc6d238c03b6ec#p107689

    Apple has 115.000 employees
    Adobe has 12.000
    Phase One has 400, 20 of them are working on C1


    I had no idea that there are only 20 people responsible for C1, wow. While I don't think we should be comparing an overall size of Apple vs Adobe vs Phase One, it would be interesting to know how many there are in the Lightroom's development team... I have no idea but I would venture a 10:1 ratio, easily.
    Apple's headcount would be close to Denmark's population, wouldn't it? 😊
    0
  • meanwhile
    I fully agree with lewisl's summary of where things are at, and what the issues are.

    The database design and memory use of Capture One doesn't need a refactor, it needs a major kick in the ass.
    0
  • xoxixox
    Hi all,
    I discover all the issues lewisl is talking about, but AFTER buying Capture One Pro 9 😂
    I naively wanted to switch from Lightroom to Capture One Pro for the Raw processor but I didn't know all the problem with the catalog part. Now I know.
    I don't understand why they don't simply stop developing the catalog part and only focus on the Raw processor ?

    does the "Media Pro 1" make a good job on Mac or it is better to stay with Lightroom for the catalog part ?
    0
  • xoxixox
    [quote="meanwhile" wrote:
    The database design and memory use of Capture One doesn't need a refactor, it needs a major kick in the ass.
    😁 😁 +1
    0
  • harald_walker
    [quote="EnderWiggins" wrote:

    Phase One has 400, 20 of them are working on C1

    Including MediaPro?

    But size isn't everything. Small teams can be very productive and create high quality software.

    So PhaseOne management has several options if they are serious about offering a 'professional' product.

    • increase the team size that is working on C1

    • hire better people (many of the bugs and issues we've seen, should have never seen the light, no matter how small the team is!)

    • reduce the work the current team has to do (e.g. drop MediaPro if it is the same team, reduce features, fewer releases, etc.)

    Those are fairly simple choices to make. Main resources obviously go into other areas of the company (e.g investing in Mamiya). Those are choices they make. On the one hand, they need C1 for their high-end cameras, but it also seems clear that C1 does not get the attention it needs (and deserves). Kind of like the situation with Aperture.
    0
  • paintbox
    [quote="xoxixox" wrote:

    does the "Media Pro 1" make a good job on Mac or it is better to stay with Lightroom for the catalog part ?


    Media Pro is a far superior catalog, but not without issues.
    It is not color managed, so your edits in C1 are more like rough estimates as far as color goes.
    I have been using C1 for a few years and can say that things have greatly improved. It seems like improvements are happening at a much quicker pace than in years past. I suppose its because there are so many new users. This is a good thing.
    Now as far as LR goes, you deal with the same limitations as Media Pro. Then only thing is, with LR you have the option of using LR's editing capabilities as well.
    Sometimmes a file just looks better in LR. I have found this to be less the case recently, but its still another option.
    Also if you were to get the CC subscription, you get the Photoshop option as well. Yet another tool!
    And printing, don't forget about printing.
    Lightroom's (and Photoshop's) softproofing is far superior to C1.
    However, I don't care for LR,PS,or C1's printing options. So I had to get Mirage Print for that.
    In essence, none of these tools do it all well, but each has strong points that keep me using them all.
    0
  • xoxixox
    thank you Jimmy D Uptain for your answer, I think I will keep lightroom that I know since first days and using C1 for developing critical Raw files, I also have a lot of filters in Lightroom and I like the printing book option directly connected to Blurb.
    0
  • Robert Farhi
    [quote="Jimmy D Uptain" wrote:

    Lightroom's (and Photoshop's) softproofing is far superior to C1.


    I agree for Photoshop. But, up to now (but I have only LR 6.4), softproofing on a second screen with Lightroom is not implemented. And, in addition, the capacity of C1 to switch instantaneously between spaces/profiles (including printers profiles) is great and suits me perfectly. The C1 softproofing fits perfectly what I get from my printer. I don't need more 😄
    0

Post is closed for comments.