Luminar 3.0.1: too easy to loose edits

Comments

42 comments

  • Avatar
    K.G. Wuensch

    If you look into the database you‘ll find that files are identified by path and a hash, change either you‘ll lose the edits. Add a file that botches the database you‘ll lose the edits (because it‘s nigh on impossible to recover the database from that). Lose your hardware to a defect or upgrade (even if you have a backup) and you‘ll lose the edits (because of the way the unique hardware ID is being used in the file identification). Lose the temporary edit state files (the edits themselves are not saved in the database) and you’ll lose your edits. Have Skylum change the algorithms (they have done so with almost every update) and your edits will have altered results (which in effect is almost as bad as outright losing the edits)... 

    6
    Comment actions Permalink
  • Avatar
    Bob Rockefeller

    This lack of data integrity is a sad mess. Professionals won't touch a product like that. Amateurs won't grasp the problem and then will be mad, later.

    It's not clear to me that Skylum understands the nature of the problem or the fragility of their database.

    7
    Comment actions Permalink
  • Avatar
    Adam Bliss

    Would love to hear from Skylum on this, if you can't move to a new computer with a backup/copy of the data and have your work live on this whole thing seems like a sham.  

    5
    Comment actions Permalink
  • Avatar
    Vereslavska Anna Veres

    We are sorry for the current inconveniences.

    We will make it easier to recover the missing file and the edits in the upcoming update that will be released within a month. 

    -2
    Comment actions Permalink
  • Avatar
    Yves Canty

    Great to hear that you're working on a solution!  I'm eager to try it out!  

    Do note that in this case, there's no "missing file".  In one case, the file is still in Luminar, only it got modified from an external source.  In the other case, the file is moved out of the Luminar catalog, and back into it.  So I do hope that Luminar will just recover automatically in these cases?

    0
    Comment actions Permalink
  • Avatar
    Bob Rockefeller

    Yes, Skylum is working on it and shows it in the 3.0.2 roadmap:

    • Locate missing folder

      Added ability to locate a missing folder

    But I'm concerned that just finding a missing folder is too short term a fix. The root of the lost image problem appears to be in the design of the database – as pointed out by K. G. above.

    2
    Comment actions Permalink
  • Avatar
    Yves Canty

    What I describe is not about locating a missing folder.

    In one of the cases I described, the image never leaves Luminar.  It's not "missing".  Do some edits on it in Luminar.  Then, from outside Luminar, edit the file, for example to change its metadata.  The file's checksum changed, so Luminar thinks it's a new file, and all your Luminar edits get lost.  I don't think there's anything left to recover or locate at that point, if Luminar just wiped the image's information it from its database and replaced it with a pristine record, for what it thinks is a new file.  Technically, the file's content did change, but from a user's perspective it's still the same image!

    It would be much more intuitive for the user, and more solid, for Luminar to use XMP sidecar files to store all edits and metadata.  Then the link between the two is simply the file name.  Very easy to "recover" from a mismatch!

    I love Luminar as an editor, but with Luminar 3, if I don't want to risk losing my hard work, the only safe way to safeguard it right now is by exporting the edited image.  Then if I even lose the edits at least I don't lose the results!

    I've read somewhere else that they'll be bringing back LMNR files in an update.  That's great, but I do hope that won't be causing even more headaches and confusion, for example if they also keep the option to have edits in the catalog like it is now?  Could then Luminar get confused and have two different sets of edits for the same file?  I hope not.

     

    0
    Comment actions Permalink
  • Avatar
    Tony Collins

    Woah

    I'd (clearly incorrectly) assumed backing up the catalog also backed up the edits (As in lightroom)

     

    Where are the edits stored?

    0
    Comment actions Permalink
  • Avatar
    Bob Rockefeller

    "Where are the edits stored?"

    As I understand it, the edits are stored in the catalog.

    The problem that some are having is that the catalog looses track of the images and so the edits and images are no longer linked. Many of the potential problems with the catalog cannot be recovered with a catalog backup!

    0
    Comment actions Permalink
  • Avatar
    Yves Canty

    The edits are stored in the catalog. The problem is how the catalog links the edits to the actual image file. In some cases the software looses that association. The edits might still be in the catalog, I don’t know, but because the association with the corresponding image ends up broken the end result for end users is that the image no longer shows any edits.

    0
    Comment actions Permalink
  • Avatar
    Yves Canty

    @Bob: Oops! I just realized you already answered! Well, it seems we both understand the problem the same way! ;-)

    0
    Comment actions Permalink
  • Avatar
    K.G. Wuensch

    No the edits are stored in separate referenced files (the already mentioned state files) which are stored in the history folder... The database has no provision for storing the data that could contain an edit otherwise...

    0
    Comment actions Permalink
  • Avatar
    Adam Bliss

    Seems like we need Skylum to give a full update here - 

    1. What is stored in the catalog?
    2. What is stored in the state files?
    3. How are they working on better identifying a file that changed outside of Luminar but is still in place?
    4. How are they working on better ways to have edits and metadata stored with the file (working on multiple machines)
    5. Proper way to migrate to a new computer without loosing work (upgrade)
    6. Proper way to re-setup from backup after a computer failure
    7. Exactly what should be getting backed up for proper recovery

    Anything else I missed?

    Adam

    1
    Comment actions Permalink
  • Avatar
    Nigel Turley

    Hmmm - I'd made the same assumption - that edits were stored in the catalog. The fact that Skylum are relying on a confused 'hybrid' solution and not using a more traditional catalog model (as per Capture One Pro etc) just makes me feel much less confident about using it, specially as I don't see them making radical changes to their setup to integrate the changes into the catalog. I just think this has been such a botched release and I'm getting much closer to dumping Luminar altogether.

    2
    Comment actions Permalink
  • Avatar
    K.G. Wuensch

    There are some quite dramatic design errors in the catalog - some are so fundamental that they are nigh on impossible to remedy because they happened at the conceptual stage:

    - Never ever (not even in a feverish nightmare) assume that you can keep a database synchronous to the filesystem operations. You need defined times when to add images - thus the „we don‘t need an import, we‘re watching the folders“ is a gruesome misconception.

    - Never ever (not even when the gates of hell open and statan is skating to work on ice) assume that images referrenced in the catalog are gone just because you can‘t find them right now. Reasons why files may disappear range from user error to defects and more often than not are not permanent. The only reasonable time that images should be removed from the catalog is when the user does so from within the catalog!

    - There needs to be a transparent way of storing the edits, so that the user knows what needs to be included in a backup or transfer to new hardware... Having to backup a history folder with a lot of redundant or even unnecessary information is nether transparent nor efficient.

    - There needs to be a robust way to identify images to link them to the DAM information and edits - a hash is only robust if you can safely assume that the file is never going to change - which happens to be a false assumption when programs like geosetter for example can change the file for  georeferencing or IPTC data are being written to the files...

     

    So in effect, the library IMHO is a catastrophic failure in it‘s current design and the needed steps to remedy that require a complete redesign!

    5
    Comment actions Permalink
  • Avatar
    Vereslavska Anna Veres

    Hi Everyone,

    Let me answer the questions:

    1. What is stored in the catalog? Previews, Cache, Backups, and Edits. 
    2. What is stored in the state files? Previews to the images that have been added to the Catalog, the edits, the info about the photos. 
    3. How are they working on better identifying a file that changed outside of Luminar but is still in place? You will be able to locate the missing folder in the next update. 
    4. How are they working on better ways to have edits and metadata stored with the file (working on multiple machines) To use Luminar 3 on several machines, you will need to have the Catalog and the images on your external HD for now. 
    5. Proper way to migrate to a new computer without losing work (upgrade). To migrate Luminar 3 to a new computer you will need to have your backups/Luminar Catalog folder and images.
    6. Proper way to re-setup from backup after a computer failure? Please see #5
    7. Exactly what should be getting backed up for proper recovery? All the images you have and the folder "Backups" which is located inside Luminar Catalog folder. 
    1
    Comment actions Permalink
  • Avatar
    Yves Canty

    Hi Anna,

    Thanks for taking the time to answer.

    On point 3, you mention "locate the missing folder".  I fail to see how that would address the case I described, where a specific image file never leaves Luminar, and has its metadata edited outside of Luminar.  Can you please clarify how that new feature will help with that case?

    On point 6, did you mean to refer to point 5?  Or are you really stating that to recover from a computer failure, one should rather put the files on an external HD so they're unaffected by the failure?

    On points 5 and 7, I checked my Luminar Catalog folder (on Mac) and it doesn't contain a Backups folder.  Instead, I have a file "Luminar catalog.luminarbackup" that is a sibling of my Luminar Catalog folder.  Is this equivalent?  I assume that single "luminarbackup" file is all that's needed to recover the catalog?

    Also, for the benefit of others reading this thread, I tried #4 and it works, as long as both the whole Luminar catalog folder and the images are stored on the external HD.  However, an important point to note is that you will need to physically connect the external HD to the machine running Luminar.  It's unusable with files on a NAS and wireless access to it.  It just seems to freezes with my 450 mb/s wireless connection.  I suppose it might work with a fast wired connection to the NAS, but I don't have the hardware to test that.

     

    2
    Comment actions Permalink
  • Avatar
    Vereslavska Anna Veres

    I am sorry for the confusion, 

    Yes, I meant the point 5(not 4).

    In order to create a backup, please click File > Catalog > Backup and you will have the file with the extension .luminarBackup. 

    With the update that will be released at the beginning of February, the backups will be created on MacOS automatically. 

    Concerning point 3, if you change the metadata of the file, Luminar 3 will not lose it. However, for now, it will not update the metadata, it will store its original metadata. Moreover, in the upcoming updates, we will add the functionality to locate the missing image.

    0
    Comment actions Permalink
  • Avatar
    Phil Hurd

    Yves, I can see the issue with modifying EXIF data is quite a problem until you can do this via Luminar 3. But I can't understand why you would want to edit an image in Luminar 3 and then move it somewhere else?

    0
    Comment actions Permalink
  • Avatar
    Yves Canty

    The files are on the file system so they can be moved at will anywhere or edited in any way, inside or outside of Luminar. Why a user would want to do these operations outside of Luminar is not important in my opinion. He just can, and that’s reason enough for the software to be able to cope with that. As a user I shouldn’t have to worry about any of this in fear of loosing edits. Library functionality is supposed to make image management simpler, not complicate it. If I have to be careful when and how I edit my images, or if I have to constantly take the tool by the hand to help it reconnect with the external changes then the tool is not helping.

    The current hybrid solution with a catalog for edits and files on the file system is the least user friendly in my opinion.

    A solution that moves the images in an opaque catalog has the benefit to make it clear to the user that the images are to be managed exclusively by the tool.

    On the other hand software that makes use of sidecar files allows the user to do what they want with the image files as long as the sidecar is next to the image with the same name. That’s easy to understand and manage for end users.

    Contrast this with Luminar that seems to really be an opaque catalog in disguise. Although it leaves the files on the file system, for a smooth experience, it seems to really expect users to only make edits with Luminar, as if the image files were in an opaque catalog. It just makes the whole user experience more complicated and confusing, as this thread discussion highlights.

    2
    Comment actions Permalink
  • Avatar
    Colin Grant

    Are we talking about editing an image in Luminar 3 and then carrying out further edits elsewhere (on the same raw)? I'm a bit confused re this editing piece :-)

     

    0
    Comment actions Permalink
  • Avatar
    Phil Hurd

    I have to say I'm a bit confused as well Colin, though I am not agreeing with you though, definitely not! :-). Why Yves Canty wants to use Luminar 2018 when he can use Luminar 3 without the catalogue functionality, I have no idea. Also why move images from one folder to another, why not copy them?

    Trouble is with all of this, it all boils down to personal preference and opinion. I personally do not like sidecar files but I know a lot of people do. I don't knock them for it but if Luminar only used sidecar files. I'd find another app.

    I also don't know why people have to sound off quite so much. I have evaluated most of the photo apps that are out there, if I don't like them, I don't use them, simples!

    My personal opinion is that when Skylum have sorted out the bugs and added some more functionality, it will suit me fine and I can dump Lightroom. For me, Luminar & Aurora provide most of my requirements in terms of photo editing, so yes I only expect to make edits with Luminar (and Aurora).

    I don't do massive amounts of editing anyway, I'd rather be out taking photographs.

    -1
    Comment actions Permalink
  • Avatar
    Colin Grant

    Oh hell, we are possibly going to agree again. I too would rather be out with the camera. I really do feel that with all the hype that goes around there are now many who see the editor as the means to the end in itself. I remember when I first starting busing Lr, I would always try to get the image as good as I could in camera and then just tweak with Lr, but only if necessary. Things have come a long way since then of course but I still like to stay in that place. In the main I like my pics to be documentary rather than artistic interpretations, but that is just me....I still like to play though :-)

    0
    Comment actions Permalink
  • Avatar
    Phil Hurd

    Yes Colin, this is becoming sad . . .

    I have a rule. If it takes me more than a couple of minutes to edit a photograph its not a 'keeper'.

    There are of course the odd one or two that are worth a bit more effort but in the main I like to get it right in camera. When I'm shooting urban landscapes with an ultra wide angle, then I leave lots of space for me to correct the verticals and then crop, in post processing but I do that knowingly. I still have to get the composition right though.

    I sometimes like to shoot HDR but not in that 'over-the-top' way, its so I can ensure I get detail in shadows and highlights and if I don't like the result I can still resort to the 0ev image in the set. Sort of belt & braces. So by definition I have to do some post-processing, even if its just merging 3 images.

    My best buddy used to have a dark room and developed his own film and prints. Nowadays he just shoots JPEG and doesn't do much post-processing, maybe a bit of cropping and that's it. He tells everyone that he shoots in RAW but lets his camera do the JPEG conversion!

    Invariably he gets thousands of 'hits' on Flickr and I've lost count of how many times he's ended up on Flickr Explore. He's just good at what he does I guess, though I'd never, ever tell him that!

     

    0
    Comment actions Permalink
  • Avatar
    Colin Grant

    I've met quite a few photographers lately who say jpeg is fine, that modern cameras do such a good job, even on auto, that the resulting jpegs are good enough to stand lite post processing (even a bit more than lite). I do shoot raw but it does make one think. Maybe RAW has gone the same way as post processing and is being over hyped - maybe that is because RAW and post are inextricably linked these days.

    0
    Comment actions Permalink
  • Avatar
    Phil Hurd

    I think JPEG is OK, as long as you are good photographer and know what you want and how to get it. For the less skilled, such as myself, shooting RAW can be a bit more forgiving. If you mess up, its much easier to change things like white balance and the like. Being able retrieve details in a RAW file that just get lost in a JPEG is also a good reason to shoot RAW.

    The image from a processed RAW file is very dependent on the RAW processing engine in the software. In this respect camera software may (or may not) do a better job, its all down to personal preference really.

    That's why I get annoyed about some of the rants on this forum, if you don't like Luminar, then get something else and move on. Personally I quite like it and its good value for money.

    Now can you please post something I can disagree Colin !!

    0
    Comment actions Permalink
  • Avatar
    Colin Grant

    I'm obviously having a benevolent day, Phil. Hopefully I'll get over it soon :-). Trouble is I'm having a bit of fun with L3. It could get me to change my views on what is my core app - but a bit more work on the dam first (not a lot though).

     

    0
    Comment actions Permalink
  • Avatar
    Phil Hurd

    Phew, I thought you were going soft for a minute there!

    0
    Comment actions Permalink
  • Avatar
    Collene G

    @Yves, @Colin, @Phil - I have been using Luminar 2018. Deciding if I want to move to Luminar 3, and this post has been very helpful.

    If I understand the discussion, it seems like this means Luminar 2018 users shouldn't move to Luminar 3 even if they just intend to use the editing only (no catalog/library), right?

    Because there is no way to save out a Luminar file in Luminar 3 like there is in Luminar 2018 and so then there is a giant risk (from what I understand of your discussion) of losing the edits. I don't understand why they didn't just stick with the model of saving out a file with the edit record since it seems super intuitive to me, though I suppose not completely elegant.

    I noticed that it seems like Luminar 2018 IS being updated on the editing side (i.e. the new AI Sky filter is now in both), so it doesn't seem like there is much drawback to sticking with Luminar 2018 for now.

     

    1
    Comment actions Permalink
  • Avatar
    Colin Grant

    @Collene, I'd stick with 2018 at least until the update (3.0.2) comes out next week. That said I have not seen any confirmation re the the issue regarding the restoration of a back-up to a disc other than that from which it originated - something that currently is not possible but much needed if you want a functional L3 and catalogue following a hard drive replacement for whatever reason.

    I do use L3, but only as a Lr plugin.

    1
    Comment actions Permalink

Please sign in to leave a comment.