MikeFromMesa Posted October 2, 2016 Share Posted October 2, 2016 I was processing some photos from a recent trip and ran into a problem I had seen a long time ago, but not since. After doing some adjustments (cloning Tool. InPainting Tool, Levels, Brightness and Contrast, Shadows and Highlights) I ended up with this. There are blocks of adjustments that should not be there and, just in case it is difficult to see where the blocks are, I have marked around them in this. The original photo was taken with a point-and-shoot which produces only jpgs, just in case that is important. It occurred to me when I was writing up this report that it would be very helpful if functionality could be added to AP to allow for the export of the history of the adjustments. That would allow users to not only describe what they had done when reporting a problem but also include the set of steps shown in the history to help the developers understand precisely what steps had been followed and in what order. This comment is meant as an official request for that functionality with the intention of helping those trying to figure out what had happened to cause a problem. Alyssajer 1 Link to comment Share on other sites More sharing options...
Staff Patrick Connor Posted October 2, 2016 Staff Share Posted October 2, 2016 Mike, do you mean like the save with history feature? Can you turn it on once you spot a problem and have it save the existing history already performed? ( I ought to know but I'm not in front of my computer right now) Patrick Connor Serif Europe Ltd Latest V2 releases on each platform Help make our apps better by joining our beta program! "There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self." W. L. Sheldon Link to comment Share on other sites More sharing options...
MikeFromMesa Posted October 2, 2016 Author Share Posted October 2, 2016 What I mean is that there ought to be some way to export the set of steps taken in adjusting an image, perhaps in text or pdf format. The information would basically be the same as that shown in the history tab, but perhaps be a bit more complete in that it would show more detail about the actual changes and perhaps also show steps that were skipped when someone stepped back in the history to do something over again or something else. The idea is that this information might be very helpful to the developers in seeing exactly what happened when processing an image that resulted in something strange or in a crash. I tried to explain what steps I took when processing the image I reported but had no way to export the steps so that the information could be included in the bug report. Before I retired I worked for many years doing dump analysis in trying to determine why a customer's system crashed. Something like this would have been very helpful to me in working out the steps that caused the problem. Link to comment Share on other sites More sharing options...
Staff Patrick Connor Posted October 2, 2016 Staff Share Posted October 2, 2016 Perhaps (during the beta) we could write the history out as text next to the autosave, but this is only really important for crashes, where you can't give us the affinity file. Using the "save undo history" feature, and sending us the file, would show all file and function problems other than import, OS and performance ones. Patrick Connor Serif Europe Ltd Latest V2 releases on each platform Help make our apps better by joining our beta program! "There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self." W. L. Sheldon Link to comment Share on other sites More sharing options...
MikeFromMesa Posted October 2, 2016 Author Share Posted October 2, 2016 I was thinking of some way to send you the processing information without having to also send the image. And, as far as I know, saving the undo history along with the image would not give you any information concerning what was done before someone "stepped back" and undid some steps along the way. That is, if I perform 20 adjustment steps and then decide to redo everything from step 7 on, you would not see steps 7-20 as they were originally done because they would have been lost when the user "stepped back" even if those steps triggered something along the way that caused the eventual problem. I assume the crash dump would provide you with most everything you would need for a crash, but I was thinking about non-crash issues. Link to comment Share on other sites More sharing options...
MikeFromMesa Posted October 2, 2016 Author Share Posted October 2, 2016 > we have architected a clever system whereby the undone things have genuinely no effect Perhaps. But I can not tell you how many times in the 25 years I worked as a software engineer and architect before I retired that I heard exactly the same thing, only to later find that there was "one tiny little problem" that ended up causing some freeze, crash or other bug. Link to comment Share on other sites More sharing options...
Chris_K Posted October 3, 2016 Share Posted October 3, 2016 Hi Mike Unfortunately I'm not able to recreate your issue easily. As I can only work within the current limitations that we have, are you able to send ma a link to the file with history saved so I can take a look through and see if it's your specific steps or a general app issue? Cheers Serif Europe Ltd - Check the latest news at www.affinity.serif.com Link to comment Share on other sites More sharing options...
MikeFromMesa Posted October 3, 2016 Author Share Posted October 3, 2016 No. I did not save that, but I will try to reproduce it. Link to comment Share on other sites More sharing options...
Staff Ben Posted October 3, 2016 Staff Share Posted October 3, 2016 At this stage it would be a significant undertaking to log each command as it is applied. We would have to add methods for turning state into meaningful text to put into a file, or a complicated framework for serialising state of objects affected by each command. Not to mention that under sandboxing rules you have to jump through hoops to write anything but the document file, so creating additional files is not trivial. This would have to be entirely separate to the history stack, as you point out, since commands can be undone and destroyed, but the undo/redo steps can potentially affect ongoing state. I don't see this happening any time soon. It's mostly the case that we can dig through crash reports or look at 'broken' files to get to the root cause of a problem. We have had a couple of bugs where sequence data might have helped, but the development time for a logging system verses the forensic debugging time would probably weigh in favour of good old fashion debugging. SerifLabs team - Affinity Developer Software engineer - Photographer - Guitarist - Philosopher iMac 27" Retina 5K (Late 2015), 4.0GHz i7, AMD Radeon R9 M395 MacBook (Early 2015), 1.3GHz Core M, Intel HD 5300 iPad Pro 10.5", 256GB Link to comment Share on other sites More sharing options...
Staff Patrick Connor Posted October 3, 2016 Staff Share Posted October 3, 2016 Thanks Ben, I was not aware of any state change issues caused by undo. Please treat Ben's answer as definitive. Patrick Connor Serif Europe Ltd Latest V2 releases on each platform Help make our apps better by joining our beta program! "There is nothing noble in being superior to your fellow man. True nobility lies in being superior to your previous self." W. L. Sheldon Link to comment Share on other sites More sharing options...
MikeFromMesa Posted October 3, 2016 Author Share Posted October 3, 2016 At this stage it would be a significant undertaking to log each command as it is applied. We would have to add methods for turning state into meaningful text to put into a file, or a complicated framework for serialising state of objects affected by each command. Not to mention that under sandboxing rules you have to jump through hoops to write anything but the document file, so creating additional files is not trivial. This would have to be entirely separate to the history stack, as you point out, since commands can be undone and destroyed, but the undo/redo steps can potentially affect ongoing state. I don't see this happening any time soon. It's mostly the case that we can dig through crash reports or look at 'broken' files to get to the root cause of a problem. We have had a couple of bugs where sequence data might have helped, but the development time for a logging system verses the forensic debugging time would probably weigh in favour of good old fashion debugging. Understood. Thanks for taking the time to explain. I will make sure that I save an image with history next time something like this pops up. Link to comment Share on other sites More sharing options...
Recommended Posts