I say goodbye to Luminar again

Comments

24 comments

  • Avatar
    Helena Carter

    Hello, Matthias. I am so sorry about your experience. Luminar 3 is our first attempt of implementation of a Library module.Sure thing, it can't be perfect with the first release, but we are collecting our users feedback and fixing all the issues which we have discovered so far. I do really hope that one day you will give it another try. Just in case, we will release an update at the end of January-beginning of February where some of the major performance issues will be addressed. We'll be glad to see you using Luminar 3 again.

  • Avatar
    K.G. Wuensch

    @Helena, your explanation is ill founded and the desaster release of Luminar 3 has destroyed a lot of the credibility Skylum had carried over from Luminar Neptune. Luminar 2018 was a badly managed release already, dropping vital functionality and showing a lack in continuity, changing the RAW conversion (to the worse I may add) at least three times over the lifespan of that version and introducing image destroying unavoidable (because it can’t be disabled) noise reduction at the RAW conversion stage.

    The „first attempt at a library“  was the excuse for a lack of bug fixes and failure to reach the promised parity between MacOS and Windows version. I was among the first telling your support people (being a software developer myself) that you have your priorities wrong because you were creating the DAM (back then the plan was much grander than the primitive library you released) on an instable code base and that this decision would come back to haunt you. This is now unfortunately a complete and utter mess, the recurrence of old bugs, host of old unfixed bugs, misconceptions (a file browser that shows images with highly variable size just to fill a line is a mess on it‘s own, any image added to such a file browser that is not put at the end requires a re-layout, thus a grid view with fixed image sizes is a must for a library that is geared for performance and efficiency and allows for unprejudiced image comparison) and plethora of new bugs are such a jumble that as a developer I would abandon the code and start anew...

  • Avatar
    Dayo Akanji

    @K.G It is a crying shame that what was really a promising software has been utterly run into the ground due to staggering levels of incompetence.

    Luminar 2017 had a lot of promise but they almost totally ruined it with Luminar 2018 and the bungled release. Having managed to sort of stabilise things, one would have thought Skylum would focus on keeping things steady and building on this but no, they jump on the DAM band wagon instead, throw out most of the code they had and basically start writing everything from the ground up.

    It is an old problem with software companies keep making over and over and over again and such companies always end up dead: Here is a famous article from 2000 discussing the issue: https://www.joelonsoftware.com/2000/04/06/things-you-should-never-do-part-i/

    In reality, Skylum probably should not yet have tried providing a Windows version and they most certainly should not have gone for the DAM at this point in time. Anyone apart from the frankly petulant LR crowd and the group at Skylum could see that taking on the development of a DAM was a recipe for disaster.

    Get the basics right before going off on a tangent. The worst thing is that despite the noise, NOBODY actually really needs a bloody DAM from Skylum as there are far better DAM tools out there that any one that seriously needs a DAM would be using as there is no way Skylum could provide proper DAM functionality for years to come. A proper DAM is a bigger program than the whole of Luminar for crying out loud!

    I completely deleted L3 and will stick with L2018 for a while but sadly, the promise I saw when I bought into Luminar as a new product back in 2016 is well and truly dead. There is no coming back unless they do what needs to be done which is the ditch the whole L3 misadventure right now.

    I think though that this will never happen as the senior management do not come across as a setup that can acknowledge such an error and with keep plugging on with the DAM. I can easily see them spending the rest of 2019 (at least) dealing with the DAM issues.

    I will repeat the advice I had posted somewhere here to Skylum:

    - Pull the L3 Release

    - Tell the user base, you might one day consider a DAM but for now, you want to focus on the getting Luminar to be best in class at its core function ... which is to edit images.

    - Asset Management is an important part of the workflow but leave that to other programs.

    - Pick up and build on L2018. Add a basic browser to this at most.

    - Stop wasting time and resources on the DAM!!

    Skylum doesn't want to build and do the "boring" incremental updates on solid existing code and want new "exciting" features but Luminar is well and truly on the path to the extreme outcomes in this article:

    https://vibratingmelon.com/2011/06/10/why-you-should-almost-never-rewrite-code-a-graphical-guide/

    So sad what is going on.

  • Avatar
    Mike Miles

    Quote from Helena Carter:
    "Luminar 3 is our first attempt of implementation of a Library module.Sure thing, it can't be perfect with the first release"

    This has got to be the most amazing statement (from a Skylum representative) that I've ever read.

    I don't know whether to laugh or cry, as it's almost an unbelievable statement. Yet it shows the utter incompetence of an organization's management and their directives

    Total chaos within an organization.

    I could probably ask a completely naive person if this was the way to develop and manage a software release and they would offer a better solution.

    For Skylum to survive, heads need to roll.

  • Avatar
    Dayo Akanji

    @Mike Miles,

    Give the support staff a break, especially new ones like "Helena Carter" who are most likely minimum wage part timers sitting in Manilla or Bangalore tasked with monitoring the forums to escalate issues that may need attention and to post generic platitudes to others to calm people down.

    The real issues are elsewhere in the organisation.

  • Avatar
    Mike Miles

    You obviously didn't read my comment.

  • Avatar
    Phil Hurd

    @Dayo Akanji, you seem hell bent on trying to persuade Skylum to dump the library functionality. As I have said before this was promised from day one, so Skylum haven't jumped on the DAM band wagon.

    I really don't know what you have against the Library functionality, unless you are an agent provocateur?

     

  • Avatar
    K.G. Wuensch

    @Phil Hurd, I too would beg Skylum to dump the ill fated library. It was clear from the very beginning that they are clueless what a DAM all encompasses and how to implement that in a meaningful way - and the "library" they released after more than 14 months stalling everything else including critical bug fixes has proven me right, they are so far our of their depths that either they admit they have bitten of more than they can chew and retract the mess or they will suffocate on their inept implementation...

  • Avatar
    Phil Hurd

    You don't think that's a little unfair on those of us who purchased the software on the basis of Library functionality then?

  • Avatar
    Colin Grant

    I do take the point but really hope they do not drown! I love the Luminar editor and V3 is working ok with Lr. In fact it works pretty well with NeoFinder on Mac and the existing Library does make a fair job of being just a browser. Maybe that is the halfway house. Get the Library working as a nice browser that can work alongside stand alone DAMs.

     

  • Avatar
    Mark Hertel

    I like the Library and it will only get better.  Sure it crashes now and then.   3.0.1 improved operations for me and not others.   What I can’t seem to grasp is why the symptoms have such a delta between end users and or their systems!  Mine is usable for sure, other say it won’t load or start, others say it crashes every minute, etc...   Are people exaggerating the issues?  Does the severity of the issues change drastically based on computer resources, interaction with other open apps or libraries used?  Feel for the people on the unusable side but for, I would hate to see the library piece go away..........I submit if someone doesn’t like it, they don’t use it.

  • Avatar
    Anders Svensson

    It would be one thing if Luminar 3 had added a Libraries feature without Luminar 2018's way of working in the process, but it didn't do that of course. I can't open a single one of my existing .lmnr files in Luminar 3: obviously a bug, but one Skylum doesn't seem to want to address. We'll apparently get an admonition to save with resources/history instead, as if that's a satisfying solution.

    Can't save .lmnr in Luminar 3 either, which at least will be addressed according to support, but who knows when that will be. Besides, even if I do resave my existing .lmnr, there's no guarantee that Luminar 3 will render them the same as 2018, so for me Luminar is turning out to be more effort than it's worth. There are other tools that aren't a random walk from release to release. (Mostly use DxO PhotoLab, but Luminar filled a couple of gaps in camera support.)

    As much as I dislike Adobe, I even went so far as to upgrade an old Lightroom 3 license to Lightroom 6 as a consequence of Luminar 3. :)

  • Avatar
    K.G. Wuensch

    I would advise against anyone using the library in it's current state, especially on a Mac because if you ever change to new hardware (be it new computer, new hard drive) you will lose your library and all the work you put into it! No backup will help because the image locations are hard coded linked to the hardware. A big design flaw that needs to be remedied before anyone should in earnest use the library for anything he wants to keep. Thinks like this show how out of depth the developers are because changing that will mean large areas of code that will need investigating and reorganising. They will also need to invest into code that allows for resynchronisation with the storage (much like Lightroom has) and they will need to expend no insignificant amount of work updating existing libraries so that they work under the new scheme and no longer link to the hardware. That alone is a mammoth task which I don't see them capable of...

  • Avatar
    Phil Hurd

    @KG Wuensch currently the Library function works for me, especially as I know it will get better

  • Avatar
    K.G. Wuensch

    @Phil, what would you say if you lose all library content you put in when Skylum fixes the major design flaw? Or you lose all library content because Skylum doesn't fix that horiffic design blunder? Because the latter is inevitable if you ever have to change hard drive or the Mac your images are stored on, the backup is worthless unless Skylum put's in a major effort to fix this!

  • Avatar
    Phil Hurd

    I think you are over-egging the issue. If I did need to change my MAC or hard-drive, I would certainly have a strategy to ensure I didn't lose my library.

  • Avatar
    Colin Grant

    Has Skylum admitted to this bug yet?

    Phil, if what @KG says is correct then how can any back-up strategy be of use if you can only restore to a hard drive that is no more? The problem seems to be that one can only restore to the original drive and not a replacement but is that only when using the Luminar on board back-up? I am just wondering if backing up to Appless Time Machine gets around this. If it does then I do  not see the issue either.

  • Avatar
    K.G. Wuensch

    The problem is that the image files are referred to by using the unique hardware identifier of the drive they reside on. If that drive no longer exists then your library is lost...

  • Avatar
    Phil Hurd

    I'd have to do a bit more work on the actual database Colin.

    From a quick look, yes the disk volume ID is in the database but surely you would replace an external drive with the same volume name? I would and I would also use the same folder structure.

    There is a PATHS table which holds the data on the Folders your images are stored in and this (I think) is linked to the VOLUMES table which, in may case, has just two records, the location of the root of my internal hard-drive (I guess this is a default) and the Image volume for my external hard drive. So its just a case of changing one single record if here were problems. Certainly it looks a fairly simple job for Skylum to have a "Change Volumes' function or something like that.

    Image data is stored by file-name.

    The Albums in the Library are linked to the images, so long as you restore your backup to the same Folder (file) structure, its not too much of a hassle.

    Also Lightroom might synchronize its Library but try re-naming your file, see what happens next!

    I still have my images in Lightroom as well as Luminar, so I'm not overly concerned.

  • Avatar
    Nigel Turley

    I've also been looking at the database - what concerns me a bit is that the UUID (Universally Unique Identifier) for a volume is also being stored. As I understand it, this is unique - hence the name - so wouldn't any attempt to move the library file to a different disk/volume fail even if the volume name was the same?

  • Avatar
    Phil Hurd

    Nigel, Library file or original image folders/files? You can move the catalogue (Library database) file to anywhere you want. The issue here is what happens if you lose the drive the images are stored on or you move your images to a different drive.

    KG "The problem is that the image files are referred to by using the unique hardware identifier of the drive they reside on. If that drive no longer exists then your library is lost..." - The individual image files do not appear to be referred to by the hardware ID. The volume does, yes but the individual files and folders are not, well only because they have a relationship with the Volume Record.

    Certainly the folders would need to be rebuilt, yes. The real issue here is whether the Albums (virtual folders if you like) will re-connect internally (within the database) with the image files once those folders have been re-built.? One easy would be to ensure that the new drive had the same database row ID as the previous drive. However this does assume that the images will have the same database ID as previous.

    So I agree its not pretty but as I said not something I am overly concerned with at the moment. The simple solution would be to stop using unique hardware IDs, I guess.

     

  • Avatar
    K.G. Wuensch

    "The simple solution would be to stop using unique hardware IDs, I guess." Doing that they would have to find alternative means to uniquely identify the images - which is basis for their USP that they keep in sync with the filesystem... But since that claim is as ludicrous as false anyway...

  • Avatar
    Phil Hurd

    KG Wuensch, your comments are not that helpful really, are they. I tend to try and be helpful, if I can, on this forum. I see no point in slagging off Skylum at every opportunity.

    If you think the software is that bad/you don't like it, then can I suggest you use something else.

    Regrads

  • Avatar
    Colin Grant

    I am is surprised that Skylum have offered no comment/reassurance on this matter.

Please sign in to leave a comment.