Notes on defects with, and complaints about, Luminar 3
First, congratulations on the release of Luminar 3! I'm certain the development staff expended considerable effort on bringing out the release. Of course, Luminar 3 for Windows appears to be an "alpha" version of the software, not even beta, and hardly a release candidate. This is a failure on the part of Luminar management, and not the developers and support staff. Please be sure that Skylum management and staff understand that management is responsible for what will surely be a very dark spot on Skylum's reputation. Management should never have promised something that could not and would not be ready in time.
These things said, Luminar 3 for Windows is currently untrustworthy, and unusable. Here is my personal list of the program's defects (bugs, oversights, complaints - whatever), limited by the fact that the program is unusable for more than short periods of time:
I. Problems with and problematic photo catalog
a. Program creates entire monolithic catalog on first run immediately after installation. Upon restart:
1. Program displays message saying it cannot properly initialize the catalog it created. It does not shut down. It does not either automatically, nor offer, to rebuild the catalog. It does not offer any exit mechanism.
2. Program hangs, leaving its startup display and a spinning blue icon.
3. Program still displays as background task, using memory, sometimes using a bit of CPU, and sometimes chattering on the internet. There is no reason fir it to be chattering on the internet.
4. The solution to this problem, per Skylum Support's "Luminar for Windows" section, is apparently to delete the monolithic catalog from the system's user's "My Pictures" directory. Indeed, this allows Luminar to start once more. But Luminar makes no effort to rebuild that monolithic catalog. Apparently, said monolithic catalog is unnecessary. In which case, why is it being built at all?
b. Program oddly wants to put catalog into the "\user\user_name\my pictures" directory on the system drive. This is not a proper directory for said photo catalog. I would never put anything at all into that directory. Any monolithic catalog should be placed either into the Luminar program directory, or somewhat better, in Luminar's "application data" directory. But see next point.
c. A single monolithic catalog is inappropriate. Catalogs (plural) should more properly be located with the data represented. For example, I keep many of my photo files (630Mb at present) on drive H:, in my "photos" directory, and organized as I see fit in various project related subdirectories. But I do =not= keep all of my photos on that drive, under that directory. Many photos are kept on other drives, in other directories. More photos are kept on removable drives, and the drive letters of removable drives often change. At this point, I am far from convinced that Luminar 3 can handle this situation.
d. As it is not presently trustworthy, and since not every user will want it, there must be a way to completely disable this photo cataloging capability.
e. There is presently no meaningful documentation on catalog processing, but see below.
e. No - I'm not going to send Skylum a copy of the catalog of all of my photos. That's a completely unreasonable request.
II. Program did not ask for registration information on first run. That really should be the first order of business, taken care of before any catalogs might be built.
III. "Something bad happened while processing image "xyz.jpg" - Try to recover it back to normal?" - This is a yes or no question, but Luminar 3 does not offer a yes or no solution. Instead, it offers four choices, none of which clearly suggest they have anything to do with recovering the photo: "Undo last step", "Clear Image history", "Move to trash", "Close Luminar 3." I certainly don't want to move the photo to trash, simply because Luminar 3 chokes on it. If that option is selected, what exactly happens?
IV. Program often simply exits. No "unrecoverable error" message. Nothing from the operating system. One moment, one is editing a photo, and the next, the application has completely disappeared with no explanation. Is there no exception handling in the application?
V. A trashcan appears below photos to the right side, with an "x" in it. What exactly happens when that is selected? If it deletes a photo, from whence is it deleted? Why is there no confirmation dialog box offered before the program takes action? When I go to trash and tell Luminar to put the photo back, why is the photo not put back anywhere on the screen? Where did the photo go?
VI. Dropdown processing:
1. With Windows applications, options generally listed under the "File" dropdown include "Open," "Close," and "Save" ( that is, "Export"). Skylum has now deliberately =removed= the "export" capability from the "File" dropdown (it was there in Luminar 2018), moving it to some sort of special control on the far right side. Nor is there an "Open" capability in that dropdown. Only an "Open Images for Quick Edit" option, whatever fine print that might involve. No "Save" or "Save As" options (but of course, "Save" in Luminar 2018 did nothing to save a photo... Only to save a file describing edits a user had made with Luminar. There is no way to actually =save= a photo with Luminar. Only "export." ). Nor is there a "Close" capability. I can see no good reason for not conforming to the standard sorts of options offered in Windows "File" dropdowns, unless it is to "think different" as Mr. Jobs recommended. Of course, "thinking differently" does not equate to "thinking better."
2. But there =is= a "Catalog" option under "Files" now. Why there, and not under some new dropdown somewhere? Apparently, one can create a "new" catalog. Or "Open" an existing catalog. Where in the user's guide are these options discussed? After the drama of Luminar 3's efforts to create some sort of master catalog, and with documentation on that "feature" quite lacking, how do I trust that part of the program in any way? When I "open" an existing catalog, or create a new one, how does that catalog then interact with the "master" catalog created at runtime (but deleted from my own system)? More broadly, how do any two catalogs interact with one another? Not at all? Does the newly opened catalog somehow replace that "master" catalog? If so, why bother to create that "master" catalog at all? When I have an active catalog describing say, photos on my drive H:, and I then open another photo from say, removable drive S:, is that drive S: photo somehow added to the catalog on drive H:? Where in the documentation are these things discussed? But again, see below.
VII. The "Layers" dropdown has been removed. In what way does this improve functionality? Would it not have been better to improve on the content of the "Layers" dropdown, thereby making the application more usable? But maybe that Layers dropdown hasn't been removed at all. Given the current state of the software, maybe it's still there, and the application simply isn't showing it. (That's how much confidence this software release inspires.)
VIII. The "Help" (documentation) function has no real "table of contents" beyond "Chapter 1," "Chapter 2," "Chapter 3," etc. , which are meaningless, nor is a search mechanism provided. "Context driven help," in which a help system is opened and the user is brought to the specific subject about which help is needed, certainly isn't on offer.
Which chapter offers a concise and complete explanation of what Luminar's new "catalog" capability is all about? I see something about "Loading Images" in chapter 8. Would that represent some small part of the cataloging process? I see something about "Organizing Images" in chapter 11. Is that another part of the cataloging process? The part that tells me I have to change from how I currently organize my photos? But then chapter 12 talks about "Using Albums to Organize Images." Meanwhile, chapter 11 talks about "Deleting files from folders," which, by the way, deletes the files from one's hard drive as well. Oh! And there's a discussing of what happens in Luminar's new trashcan feature. What a lucky thing for me to have stumbled across in this unsearchable user's guide! Because simply stumbling across the chapter 11 subject of "Deleting Files from Folders" really doesn't suggest to me that there will be a discussion of Luminar's trashcan.
All of which is to say that the user's guide is quite unfriendly. It should be reorganized to include a clear section describing all the features and drama and dangers entailed in the cataloging system, at least, with clear labels indicating chapter contents, not just "Chapter 1," "Chapter 2," and etc. It should be searchable as well.
Is a PDF version of any documentation available? Because even PDF files can be searched for terms.
IX. Hovering over the odd little "Up Arrow" in the menu bar doesn't tell one anything. Clicking on it, however, reveals that it's a one way street out of the set of photos one has displayed for quick edit. If there is a way to go back into the "quick view" for the set of photos previously displayed, it's far from obvious.
X. Why are all the keyboard shortcuts available on the Mac version of the program not available on the Windows version? This should hardly be a difficult thing to accomplish, nor really all that time consuming. It should entail little more than a separate module(s) invoked to interpret keyboard inputs for both Windows and Mac which would return an indication of the action to be taken. Or perhaps the original developers littered Mac specific keyboard processing throughout the application's code? It wouldn't be the first time I've seen developers do such. Not to worry... Wherever there is (Mac specific) keyboard input processing, replace all that with a call to a new module, passing the keyboard input to a function or object or whatever therein. That new module can then examine the input, generate some code or token in the process representing a function request for either Mac or Windows, and then return to the caller so that the necessary processing for that input can be performed. Or, feel free to come up with some other mechanism. But either way, this is hardly rocket science. However tedious, THIS IS SIMPLE STUFF. I know because I've had to deal with it in the past. Let me know if you want to farm that job out to me...
XI. Regarding the "fix" for photo preview not working in the absence of an Internet connection, why, exactly, is an Internet connection expected? What, if any, data is being passed back to Skylum? I did not give Skylum permission to collect any data from my system. How do I disable Luminar communication with Skylum? Firewall only, or has Skylum provided some mechanism to prevent Luminar communication with Skylum?
XII. Why can not the "Free Transform" function support changes in perspective (widening/narrowing the top and bottom of images)?
XIII. Is there a selection of alternate brushes available anywhere? Because the one built-in paintbrush that I've seen is pretty fuzzy and imprecise, and does not inspire confidence when working with masks and layers.
I think that's enough at this time. Remember - the comments are intended to be constructive. I look forward to a time when Luminar 3 performs as it should, and includes complete documentation.
I assume the developers are presently burning the midnight oil. I hope they get overtime pay. The same for Skylum's customer support representatives. They've always done quite a good job, in my opinion. They must find it extremely taxing, perhaps even painful, to deal with so many upset customers.
For now, I will continue using Luminar 2018, as the current version of Luminar 3 adds nothing I need or can trust. I will check back from time to time, however.
Take from this message what you will. The best of luck to you all.
-
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.
-
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.
-
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
-
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."
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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.
-
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
-
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.
Please sign in to leave a comment.
Comments
17 comments