Notes on defects with, and complaints about, Luminar 3

Comments

17 comments

  • Avatar
    Anna Veres

    Hi Kenneth,

    Thank you for writing such a descriptive message to us, I will forward your comments to the person in charge for further consideration.

    Concerning the part V and III, when you delete the image, it goes to the Trash folder inside of the programme. You can go to Trash and bring this image back. It will come back to the Folder where it was originally located.

    Regarding the user guide(documentation), you can download it in PDF from the link below: https://www.dropbox.com/s/2fhnni2xdvlthda/Luminar%20User%20Guide_1.pdf?dl=0 

     

    We are going to release the hotfix for Luminar 3 later this month. 

    As we have already promised, we will release free updates to Luminar 3 until late 2019. 

     

    1
    Comment actions Permalink
  • Avatar
    Kenneth Roach

    Of course, I forgot at least one...

    XIV. After importing a file from say directory \xx\yy, then when exporting the same file, Luminar always defaults to the previous output directory. If I had last exported a file to say directory \xx\zz, Luminar continues to want to output the new file to directory \xx\zz, requiring that I change the output directory almost every time, and to the extent that I forget to do so, my system gets littered with files output to the wrong location. After some thought, it seems possible that someone at Skylum might be following Mr. Jobs' advice and is trying to "think different." That is, someone, somewhere, might think this is actually a feature -- to always output exported files to the same directory, no matter their original source directory, unless the user remembers to change it. But Luminar is the =only= application that I've ever seen behave in this way, and I consider this to be a real defect. An extremely annoying, absurd, and ridiculous one at that. For each photo, the default output directory for export should be the same directory from which the original file to be edited was loaded. If it was loaded from directory \xx\yy, then Luminar's first option for output should be to directory \xx\yy. If the people at Luminar disagree, then this should be a configurable item, to be managed on a presently non-existing "Preferences" page. It isn't much fun to have to argue with the application about this on an ongoing basis.

    0
    Comment actions Permalink
  • Avatar
    Matt Savard

    Good luck on getting that changed. Ive been complaining about it since the first release and was just told is was designed that way on purpose. :(

    https://community.skylum.com/hc/en-us/community/posts/360034548192-Exporting-files 

     

    1
    Comment actions Permalink
  • Avatar
    Kenneth Roach

    I had missed your post (so many lately). Good to see others are in agreement. Thanks, Matt.

    I consider it a serious defect in need of correction, and too, know that correction of this matter in the way you suggest would involve very little software effort. But then, there is someone from Skylum in your post trying to defend the current processing as if it is a feature, and not a bug. And I must assume Denis was in fact told that this was "the correct answer" by a developer or manager somewhere.

    I'm reminded of something I once overheard someone say to another: "Everyone else in the world is content with a round anal orifice. Why do you have to have a square one?" Only of course, the word actually used was a bit more graphic than "anal orifice." Perhaps that's the way things are with one or more of the people at Skylum.

    That kind of thinking is, of course, incorrect. The people at Skylum surely want a top notch product that no one complains about. They will hopefully figure this out some day, stop being defensive, and listen to their customers when the customers tell them something is defective and needs to be corrected. There is no virtue in making customers work harder in any way just because someone wants to "think different."

     

    0
    Comment actions Permalink
  • Avatar
    Kenneth Roach

    And another matter finally remembered:

    XV. Plugin processing is lacking. I do not use adobe products, so could care less about using Luminar as a plugin for either photoshop or lightroom, nor using adobe products as plugins for Luminar.

    Luminar =almost= works as a plug-in for Corel's PaintShop Pro 2018. That is, PaintShop Pro can invoke Luminar, but displays only a black screen when it should display a passed image. The Gimp photo editor has better luck -- I can invoke Luminar 3 from Gimp, but edits made in Luminar are not later re-loaded into Gimp. It would be nice if Luminar supported using and being used as a plugin with non-adobe products, but I am not holding my breath for such support to appear. In the absence of additional hand holding sorts of plugin support, it would be good if Skylum could completely document Luminar's plugin processing. That would allow users greater success in adding their own plugin processing.

    More specifically, I can say that I have no problem using the Nik filters as plugins in the Gimp program. But the Nik filters provide the ability to simply SAVE the image being edited. When this is done, it saves on top of the original input image. That image is then reloaded by Gimp. Luminar does not provide a capability such as this. There is no SAVE option that updates the original input file. If there were, then I could probably successfully use Luminar as a plugin to Gimp. Of course, I would rather use Gimp/PaintShop Pro as plugins for Luminar, but that option appears not to be on the table for a very long time.

    Thanks again to all the folks at Skylum, for trying to make a truly great photo editor! Remember -- My comments are only intended as efforts to make Luminar even better.

     

     

     

    0
    Comment actions Permalink
  • Avatar
    Kenneth Roach

    An aside - Merry Christmas and Happy New Year to all the developers and customer support representatives at Skylum, who have been forced to work on Luminar 3 bug fixes during the holiday season. Your hard work =is= appreciated by at least one guy living in the hinterlands of Thailand. Thank you. That said, you might ask those in charge of release scheduling why they chose to release shortly before the holiday season rather than after, say, in the first few days of January. One really must wonder what those in charge of release scheduling were thinking.

    Again -- Merry Christmas and Happy New Year.

    3
    Comment actions Permalink
  • Avatar
    Dave Boettcher

    Or, they are using an attorney to help draft answers whic are not an admission of responsibility.

    0
    Comment actions Permalink
  • Avatar
    Uli Spalthoff

    Thank you, Kenneth, for summarizing all these issues. Many of them exactly describe what annoyed me when I tried to come to terms with Luminar 3. The library has even more issues. For instance, there is no way to get rid of a folder in the library if I delete it using Windows file explorer, while Luminar is running. Clearly, the tutorial videos do not describe the present state of the software.

    Nevertheless, I agree with your kind words and season's greetings to the developers.

    0
    Comment actions Permalink
  • Avatar
    Charles Dexter Ward

    Luminar 3 doesn't save the FREE TRANFORMATIONs i've done on my photo. I have to do it every time i start the programm

    0
    Comment actions Permalink
  • Avatar
    Kenneth Roach

    Haven't heard of that problem yet, Charles. I confess that I continue to use Luminar 2018, and not Luminar 3. Whatever fixes may have been in the last December release didn't prevent it from crapping out on me within 15 minutes or so. I've seen no evidence of any "Quality Assurance" in Luminar 3. If there was any QA -- any testing at all -- it seems the testers were ignored. Or that there was no QA at all. Either way, Skylum management does as it wishes, customers be damned. Very well. At least they're giving us free patches, etc., throughout 2019, or at least most of it. We will have to see what Luminar 3 looks like in 6-9 months time.

    0
    Comment actions Permalink
  • Avatar
    Charles Dexter Ward

    Maybe I should do the same. Just worked on a photo and when i exported it to JEPG it looked very different to the version I was working on. 

    And you'r right. It works so much slower than the 2018 version. It takes ages to apply any changes.

    I really hope that they really fix all of these.

    0
    Comment actions Permalink
  • Avatar
    Charles Dexter Ward

    Here are some more issues i found:

    1) How  can i move in a photo when i'm zoomed in? Had the problem when i was dodge&burning. In Lightroom i could hold space and move to an other section of the picture and keep on working without zooming out. 

     

    2) Another problem is, that exported pictures in jpg format a much more darker than the RAW files i worked on in Luminar. 

     
     
     
    0
    Comment actions Permalink
  • Avatar
    Charles Dexter Ward

    Another problem occurred.

     

    When i copy the adjustments of one picture an paste it to another picture, Luminar just copys the hole picture i've worked on before an deletes the one where i wantet to add the adjustments.

    I really think we are still in the alpha-phase of testing!

    1
    Comment actions Permalink
  • Avatar
    Denis Kotsee

    If you have another image layer in the photo you're using as a source for the sync, that image layer will also get copied. This is known behavior, we'll change it in one of the future updates. You can remove the uppermost layer in the photos you synced and only the adjustments will remain there.

    0
    Comment actions Permalink
  • Avatar
    Kenneth Roach

    I haven't noticed any problems with speed, Charles, but my computer is among the fastest around, so I probably wouldn't notice any slowness.

     

    About your problem with photos that look "very different" from the original input photo -- different in what way? I am going to assume in terms of color - brightness, contrast and etc. I have noticed some difficulties on the part of various Windows programs when trying to render "the adobeRGB" color space rather than just "sRGB." Could you be having problems in that regard? I could be wrong, but when last I checked on this, it seemed to me that it was Windows 10 that actually had trouble displaying the images properly, and not the image editing programs. If this is the problem you're experiencing, you might try converting the image to "sRGB" instead of "adobeRGB" and see if that helps. If that isn't the problem, then additional information would probably be helpful to Skylum.

    Ken

    0
    Comment actions Permalink
  • Avatar
    Charles Dexter Ward

    Thank you Ken,

    that might be the problem. I have the adobeRGB setting in my camera. And i also work on windows 10. And yes, it's mostly the problem, that the exported jpg photo is much darker than the RAW file.

    I will test it.

     

    THX

    0
    Comment actions Permalink
  • Avatar
    michael mills

    I totally agree with Kenneth's concern with the file import/export location philosophy. See his post: "XIV. After importing a file from say directory \xx\yy, then when exporting the same file, Luminar always defaults to the previous output directory." Aurora does the same thing and I constantly have to remind myself to check which directories are in use for both importing files and also exporting files. I think the default should be that all files should be imported and exported to/from the same originating directory unless the end user chooses to make an exception to that rule. I also think that if you drag and drop files onto the Luminar/Aurora ICON as I do, the software should automatically know what directory the input came from and automatically switch to using the directory/folder that was the source, for future improrts/exports until such time the user makes a different choice of a different directory/folder. This is how most software behaves currently. I also have found myself having to do significant clean up to move files that were exported to the wrong folder and it's very frustrating to have to do so.

    0
    Comment actions Permalink

Please sign in to leave a comment.