Aurora HDR 2019 crashes when trying to load a .auh file
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.
Please sign in to leave a comment.
Comments
20 comments