Aurora HDR 2019 crashes when trying to load a .auh file
Answered
Aurora HDR 2019 crashes without warning when I try to load a previously save HDR (.auh) file. It seems to happen right about the time the picture should actually render on the screen. It only happened with a true HDR made with more than one image, not with one made with a single image. I believe it only happened if the image is cropped, which I do with most images. I have been able to do a work around by saving before I crop and never saving after the crop. It took quite a while to figure that out because I usually crop first thing in my workflow. It would be great if you could address that in the next update as it works perfectly otherwise.
-
Tom, Paul, I'm sorry to hear that you've encountered this issue. Could you please let me know what is the format of your source photos? What camera are they shot on?
Also, are you able to reliably reproduce the crash by doing just the following:
- open image in Aurora
- apply crop
- save Aurora document
- restart Aurora
- try to open the document you saved in Step 3
-
As stated in my original post; it works just fine with a SINGLE image. Using 2 images however: Doing nothing other than a crop produces an .auh that will successfully reload. I repeated this time enabling ghost reduction, auto align and a crop with no other edits which produced an .auh that just sat indefinitely at "making it awesome". This is a new behavior, normally Aurora just disappears and I'm back at the desktop.
-
Windows 10 64 bit, Intel 620 graphics card, Nikon D7100, .NEF format. Aurora HDR 2019.
1. Opened Aurora. Selected 3 .NEF photos. No crop; No editing. Saved .auh file. Reopened file. Opened correctly.
2. Opened Aurora. Selected 3 .NEF photos. Selected 'Auto Align'. No Crop. No editing. Saved .auh file. Reopened file. Opened correctly.
3. Opened Aurora. Selected 3 .NEF photos. Selected 'Auto Align'. Cropped composite image. No editing. Saved .auh file. Reopened file. Program CRASHED.
-
Tom, Paul, thank you for getting back to me. I'm sorry I'm late with my reply.
I got a response from the QA team yesterday about this issue: it seems to be connected to either alignment+ghost reduction+crop or chromatic aberration removal+crop. Anyway, we're working on resolving this issue before the next update for Aurora.
-
I am having this problem too. Wow is all I can say that here I am buying the software four months after this problem was identified and the consumer did the software QA to document it and a patch/fix has still not been implemented. Why are these issues not listed in the FAQ and a newbie like me has to do a google search to even find this thread in the forums?
-
Hi Michael. Please contact us via https://skylum.com/support and we will do our best to help you.
-
Is there a solution for this? I contacted support and received the standard, "It will be fixed in the next update" which we are still waiting for. This is not just an inconvenience, this is a critical flaw that has brought our work to a stand-still. I have had 40 images in limbo since February with no solution in sight. Will there be an incremental update to fix this or are you waiting to fix this in the next full update? Do you have an estimate of when we can expect this to be fixed?
-
Hey Alan - I don't work for Skylum and don't know why they don't put some workarounds on the FAQ. I found and others have posted in an other thread that you should be able to use this work-around. 1) Don't crop your HDR images before saving the auh file. 2) Do all cropping post saving of the auh.
If you do this, the auh should load OK without crashing Aurora. It is not optimal but better than being stuck with no way forward. The bug is that images already cropped cause a problem while uncropped ones seem to work OK.
Hope that helps you. You sound pretty frustrated which all I can say is I've been there too. Good luck. Hopefully Skylum will do something for us that have been experiencing these problems beyond "I'm sorry".
-
Hey Michael, thanks for the post.
Yes I did see the work-around of not cropping in Aurora. While it's a workable option moving forward, as you noted, it doesn't help for any in-progress files. I've seen other software companies fix less critical issues than this in a matter of days. I'm just surprised and frustrated that this work-stopping, critical flaw hasn't been fixed yet. My experience with Skylum software has been frustrating to say the least with a history of software bugs and problems in both Aurora 2018 and 2019.
Anyway, all that aside, thanks for reaching out and for taking the time to document this work-around for anyone that may come across this thread.
-
@david quillman All I can say is I've been there man. And, I understand the frustration. After going through this so many times, my workflow just sort of automatically follows the work-around and I don't think about this much anymore.
But, why there is not some kind pf auto-sensing of the fact you cropped the photo and at a bare minimum, you get a message that this will not work, I don't know. Even though this is pretty cool software, one gets the impression it is a very small company with scarce resources.
-
The "now what" is that you wait around indefinitely for Skylum to do nothing about it, or repeat your edit without crop. I have been waiting almost a year for a fix and finally decided to re-do many hours of edits for quite a few images. I have no hope that this or any of the other reported major bugs will be fixed. Meanwhile, other software companies are putting out regular updates for issues far less problematic than this. This thread was started 10 months ago and there is still no update or fix. So if you can wait, maybe there will be a fix, maybe there won't. The good news is that maybe you are closer to a fix than the rest of us were 10 months ago. Maybe someone from Skylum will chime in here and give you some concrete information other than "we're working on it." Ultimately, you have to decide how long you are willing to wait before starting over.
-
@SKYLUM TEAM
MORE THAN A YEAR AGO, MULTIPLE USERS REPORTED THIS FUNDAMENTAL ISSUE.......
I HAVE ABOUT 10 PROJECT FILES WHICH I WORKED ON TODAY THAT NOW WON'T OPEN.
IT'S CLEAR TO ME THAT ANY COMBINATION OF "TRANSFORM" (IE A ROTATE, VERTICAL, ETC.), "CROP", AND "VINETTE"; IN ANY ORDER CAUSES THIS ISSUE. IT'S NOT JUST CROP.
WE ALL WANT TO HEAR THE ETA FOR THIS FIX!!!! THE FIX HAS TO INCLUDE THE ABILITY TO OPEN CURRENT CORRUPTED FILES.
THIS BUG FIX FOR SUCH FUNDAMENTAL FUNCTIONALITY HAS TO BE PRIORITY ONE OR YOU WON'T HAVE TO WORRY ABOUT CREATING AURORA 2021 BECAUSE THERE WON'T BE ANY CUSTOMERS FOR IT...... FOR GOD SAKES - LISTEN TO YOUR CUSTOMERS! WE ARE JUST TRYING TO HELP AND WE KNOW BETTER THAN ANYONE ELSE WHAT WE NEED.
-
SORRY BUT AFTER MORE THAN A YEAR OF REPORTING THIS ISSUE, THAT ANSWER DOESN'T CUT IT ANY MORE.
THE PROJECT MANAGEMENT AND MARKETING 101/PRIMARY RULE - LISTEN AND WORK WITH YOUR CUSTOMERS TO FIX BUGS AND DEVELOP NEW FEATURES IN A TIMELY MANNER.
APPARENTLY SOMEONE DOESN'T UNDERSTAND THIS FUNDAMENTAL PRINCIPAL. WHOEVER AT SKYLUM IS CHOOSING TO VIOLATE THAT PRINCIPAL SHOULD BE LET GO AND REPLACED WITH SOMEONE WHO DOES KNOW HOW TO MANAGE THIS.
UNRESPONSIVENESS IS THE SKYLUM ACHILLES HEAL. ....AND ON THE OTHER HAND, YOU ARE LISTENING WAY TOO MUCH TO THE WRONG GROUP OF "PRO ??" CONTRIBUTORS FOR PRIORITIES.
-
SKYLUM TEAM - Here are some light management articles the team needs to seriously consider - to be a market contender (...and there are many more on the subject):
1A) https://www.smart-jokes.org/how-it-projects-really-work.html
-
michael mills We have replied to your email. As we noted, we do listen to our customers and their requests. Our team is working on all the reported bugs. This bug is reported.
We are sorry that this issue wasn't fixed yet but still we can't give you the timeline yet. -
@Anastasia
Really.... Really.....
I don't know how you say that with a straight face.
More than a year gone by.......
I've personally worked on software projects worth tens of millions, even hundreds of millions of dollars and I know better.
In the buis we call this bug a sev1 (high priority). I would have had this solutioned & fixed, even with a small team, within a week or two at most.
You need to do better for your customers!!!!
Fellow End Users & Customers - please weigh in here....
-
Yep, I learned the hard way not realizing this. It's unfortunate I like the program but it seems like we are hanging in limbo with this major bug. It should be fixed it a big issue and I feel like we are left hanging as support say's it on the to-do list but because of Luminar AI it's put on the back seat. It has not been fixed in two years look at the date of this post.
-
@Bill - there are several interacting factors you need to be aware that I have found will cause this experience. If you use the transform function (like to straighten a building or to slightly rotate the image) this can create the issue you are experiencing. Cropping can cause this same issue. I have also seen that if you use vignette (which I do) in combination with some of these functions, you can also have this experience. So a lousy work around is to use these functions at the very last stage of your edits. Save all your edits that you have done prior to using these functions, make the crop or transform or vignette edits last but, don't save them as a project file just export them to a jpeg. I have also tried this trick that sometimes works but not always, I keep the basic edits like exposure, white balance, color shifts, any masks I do in one project file, apply the crop or transform as the very last thing and then do a "save as" to a new .auth. Sometimes that works and you can reopen that new .auth file but even if it doesn't work then you still have the pre crop/transform .auth file to reopen and work from that has most of your work saved. I hope what I said makes sense or maybe I just confused this more. Yes, this is a problem for about two years now and it is hard to accept that a problem of this severity hasn't yet been fixed - I don't care what the excuse is.
Please sign in to leave a comment.
Comments
33 comments