hy13

@Dan C Just to complete the sequence above: Installed beta 2.2.1931 five minutes ago. Other than with version 2.2.1930 this version no longer crashes when loading *.afphoto files edited with version 2.2.18xx. Therefore no new thread necessary. Good to see that things proceed.

@Dan C Thanks for reopening the NVIDIA Optimize thread. I will check on my computer if this parameter is available and change accordingly. Meanwhile I replaced the Game ready Driver with the latest Studio driver. It seems like the crashes after select operations are gone. Those with different Beta versions are still there. Next I will recheck the crash dump paths and open a new thread for Beta versions crash.

@Dan C Hi, thanks for your recommendation regarding screen recording. I will try to get it in use. I will answer your other requests asap. Regarding crash dumps I did not find any so far, but in spite of that I will follow your steps once more to be sure. The critical software you referenced is not on my computer. Only the NVIDIA Optimization I do not know. The link given in your NVIDIA chapter is not working for me (says "you are not allowed...)

@Dan C Addentum to previous post regarding crashes: *.afphoto files crash beta 2.2.1903 at loading when stored under previous beta.

@Dan C Here is what I recorded from screen, this time with Beta V 2.2.1903: There are four screen shots: the first (selection A2) shows the polygonal selection made, the second (selection B2) shows the refine screen without any changes, the third screen shot (selection C2) shows the 4 pixels added and finally the fourth shot (selection D2) shows the deformed selection result after returning from refine. During refine nothing else was done besides the 4 pixel transparency add. I know from your tutorial videos that there are better tools for screen recording available. If you have a recommendation for me, I will check if I could afford to license it. The crash afterwards (when next picture was loaded for edit) is independent of the selection method (with or without refine) and independent of a color change inside the selection, happens after edit with clone tool inside selection as well. But please note: The actual edit where these selections are done finishes all the time without a problem. The crash occurs after opening the next picture for edit. The sequence is: Open picture, edit with selection, save picture, close picture, open another picture, touch anything --> crash. Edits without any selections do not crash the next picture edit.

@Dan C I will add an extended workflow for the selection issue the next days. Referring crashes: They occur in beta and 2.1 final. One can use every picture to provoke that. The mechanism is always in that sequence: Use a polygonal selection during edit and change the color inside the selected area. Optional you can do further edits. For the moment nothing bad happens and one can save the edited pic without problems. But after opening the next picture for edit you will see the crash when touching any GUI element now, for almost 100%. The common factor is RAW format ending .ORF

@Dan CIllustration of Selection issue: In Selection_2 you see a polygonal selection with pixelwidth 0. This selection was refined in Refine dialogue using 4 pixels of transparency. The result is to be seen in selection_3. The next picture (Selection_4) shows a crippled line in the respect section of the drivers back. Selection 5 shows another polygonal selection with pixelwidth of 4 and Selection_6 shows the result without refine. This time smooth as expected. The next picture edit afterwards crashed AP 2.2 when touching the first GUI element by mouse click. This behavior can be reproduced on my machine with various clicked GUI elements. So it is not dependent on the specific clicked GUI element, I guess.

@Dan CScreenshots to illustrate Preset issue for the detailed tab: In Preset_3 you can see that there is a preset, named Denoise, is defined. In Preset 4 you see, that this preset is active, but no value was transferred

@Dan C First of all: it is not a temperature problem of the graphics card, instead it depends on the type of operations within AP. When I use polygonal selections with a transparency of some (2 to 4) pixels followed by a color change of the selected object I will see a crash of AP when editing the next picture. When I do not use the said functions, AP remains stable (tested 15 pictures in a row) more than once. Nevertheless I will check the driver Version the next days. Develop preset: in the details tab I tried to keep the luminance noise reduction value set by slider for further edits by defining and storing a named custom preset other than standard. The preset sometimes disappeared in the next picture edit. Mostly however, the preset name was there, but the value not used in following edits. I try to provide screenshots of the workflow the next time. Selections: There are two ways to make the border of a polygonal selection transparent (in order to avoid a hard edge). I can define a pixel value before starting the selection or I can use the refine dialog after the selection loop was closed. Using the latter I saw a deviation from the selection loop afterwards which was a lot more than the chosen transparency value (3 pixels chosen, 15 to 20 pixels seen afterwards). Here as well I will try to make screenshots for you. The installation method for AP is via *.exe because I need to transfer pics from otherwhere to AP for editing and I use Nik as well as Portrait pro.

@Dan C Further investigations in 2.2 beta led to: - there was no crashdump in %appdata%\Affinity\Photo\2.0\CrashReports\reports or %appdata%\Affinity\Photo\2.0 beta\CrashReports\reports, the named subpathes ...Crashreports/reports do not exist - there might be a temperature problem with the graphics card, I will check that further the next days and report afterwards what is left so far are two things: 1. develop persona does not keep saved parameters (tested with denoise luminance) 2. refine selection destroys any previous selection made when using transparency width of 2 to 4 pixels, selection border is jagged after operation and borderline no longer smooth

@Dan C Photo final, which I reported first is V 2.1.1 Then I downloaded Photo beta V 2.2.0.1881 and found out that crash rate is even higher than in V2.2.1 Best regards

Sorry for beeing unable to give more detailed information. All what I can report is, that in both versions, 2.1 final and 2.2 beta there are frequent crashes. This means after editing of 2 or 3 pictures, affinity disappears immediately from the screen when one touches any GUI element, mostly in develop persona, without leaving any message (jump into system and disappear was the wording used earlier for such a behavior). The only thing one can reproduce is, that it happens for sure after short editing work. What was watched beside it is, that all parameter changes which were done before, during a seldom non crashed edit, are gone after the later crash event. Thus, after changing the standard preset in develop persona (here denoise value), and storing it to a new configuration it was lost after the crash. One time the stored name was still there but not the set parameter, the other time both, name and parameter value, were missing. What I can supply above that is, that my actual edit work was very simple. Open file in develop persona, edit parameters luminance, shadows and lights. Then develop. In edit persona duplicate raw file, sharpen, straight picture to horizontal, select a detail by polygon, change color of detail, store and export to jpg. By the way, when a selection was done with pixel width 0 or 2 an refine afterwards with 3 pixels destroys the selection more or less. The deviation of the intended width of appr. 4 pixels is above of 30 pixels in certain places afterwards. Conclusion: I will stop the test of 2.2 beta for now because an average crash rate of 2 per 3 pics is too much for doing meaningful tests. Operating system is win 10 pro with 64 GB of RAM where Photo V1 works very stable so far. Please advice how to do a screen recording in win.

As before in V2.0 there are still various crashes, mostly when using crop tool and perspective filter. Crashes happen when you touch egde points or lines of the named tools. Sometimes an erased area is shown instead if the pictures, but mostly photo crashes without any message or faulty reaction, just disappears from the screen. Seen in windows 10

@AshIs this an error? Crop tool, unconstraint mode, default A picture is open and a second picture was placed somewhere on top of it. Then crop tool was opened and some turn was applied. When I decide now to discard the change(turn) then I get 2 different results: 1. pressing ESC button discards the change as expected. 2. Choosing Break (next to Apply) does not discard the change, instead keeps it applied and exits crop tool. When active layer is changed from the second picture to the first picture, before discarding, then 1. and 2. both discard the change as expected. Without the 2nd picture on top this above behavior was not seen.

This is a welcome improvement. Works as expected in my first test. Thank you.

The listed Improvements are welcome. My first test shows good results. Like "NotmyFault" above I would like the anchor point setting to be added. I would not like the Spiral overlay as a default. It is not really handy in use. A golden section grid would be better if the thirds default is no longer welcome. For me the thirds grid still is Ok.

@dominikNothing against an "expert" mode or something like that, but as we talk in this case of option keys, that would be kind of expert mode already, I think.

@dominikWell, I can understand your position, because I suffer from that just right now. My approach therefore is: leave the step by step procedure for those who like it safe and enable additional intuitive speed workflow for those who need it to get their work done. At present, when starting an editing session after a new shooting, I have to follow the sequence Open RAW-->Edit-->Save as... and then Export-->Save and finally Save-->Close, whereas Save-->Close are logically two unnecessary actions because I do not alter pics after exporting, AP on the other side requests for system reasons always an extra Save after exporting. When I want to avoid this, I could alter the sequence like: Open RAW-->Edit, then Export-->Save as... then again Save as... (because AP does not remember the Export path just used) and finally Close. That is shorter, however the danger to store "somewhere" is huge, because one must do the Save as.. twice. Whenever you forget to set the new path you will have to search for your files later. Conclusion: When you want to speed up there is always the risk for errors, but the above proposed way seems to me more intuitive whereas the existing Workflow needs more concentration to avoid errors. For all those who normally edit 2 or 3 files per session that makes no difference. But those who use the editor often with reasonable amounts of files it would be a help. And, the solution proposed by Ash is a way that other software vendors use a lot and I found it ok as well when AP would implement it instead of my proposal. On the other hand: How often do you open a bunch of documents? For Panorama, HDR and Stacking workflows there exist already dedicated solutions. And complex compositings for most users certainly are a rare work. But the CloseAll command is ok for me, nevertheless.

@AshThanks for your reply. Extending macro functionality would be nice. But will there be a chance to do so shorthand (V2.2) ? The other way, which you mentioned above, too, seems a lot easier. After one once had supplied a path, one could reuse that until it is changed by "Save as..." instruction. This would work for export as well as for other save operations. There is no extra config operation necessary, but it would be great to save paths by type of operation automatically (e.g. one for export and one for *.afphoto, for designer and publisher there may be additional ones, but I think they will be limited in number). And whenever "Close&Save" will be used, AP looks for a stored path and uses this one in one shot without further dialog, or calls "Save as.." operation instead when there is no path available yet.

@Ash Well, you are right. And this is included in V2.0 already. But that was not what I wanted to propose. Sorry for being not precise enough. I was thinking of a one step "Save & Close" operation without additional Yes/No Dialog box and this operation should also include the automatic deduction of the *.afphoto name from the opened source file (RAW, JPEG or other) if not defined otherwise already. So 12345.RAW e.g. would be saved as 12345.afphoto, on the same directory path where the RAW came from, without further dialog operation. This would enable the workflow: Open RAW --> Edit --> Save&Close without additional save and naming operation. An alternate way to do so would be the use of macros, but the "Save" and "Close" functions are not available for macro recording (same as in V1). The "Close All" command is for sure a useful extension (when there is no need for affirmation on a file by file basis). I think, however, that in straight forward photo editing, e.g. after a holiday where 50 photos are to be processed in one sequence, it is more common to have only one file open at a time. To stick to my sample: 50 files open at once for editing would end up in a mess for me.

What about "Save & Close" as an Option? Would speed up workflow a lot.

As far as my checks showed: The preset is forgotten too when changing pics or closing the application. Grid presets and other settings are stored 'per document' as noted above. But that is useless when you intend to edit a series of new pics. Best may be to wait until V2.1 will be released and then test again.

@Miguel del Rio As we got to know in between, Serif changed the behavior of the grid function. Automatic mode in V2 now shows the new "pixel grid" which is so tiny that you don't recognize it in a normal zoom state. This pixel grid did not exist in V1. OK so far. But what does not work properly on my computer is the "Basic" mode. In this mode you can define your own grid spacing and color. But Photo V2 does not keep this setting. When you load another picture, than Photo V2 automatically sets the mode back to "automatic" which is again the not wanted pixel grid. At present, the only solution for those who want to use the V1 grid function as known before is to write a macro which sets the "basic" mode each time you need it on a one click basis. V2 can keep the user defined color and spacing values, but not the mode setting, what I classify as a bug because it hinders the workflow.

@walt.farrell general statements: V1 and V2 share the same computer and operating system and no change in hardware so far. further test results: 1. changing the key table entry from CTRL+' to CTRL+# makes the key mechanism work. This results from the fact, that one needs to press the SHIFT key, which is not indicated in the dialog text. There is written CTRL+' and not CTRL+SHIFT+'. Different software behaves different at that point, but OK. 2. In V1 the grid mode is set to "automatic" mode as default and switching grid from on to off and vice versa works fine in that mode. 3. in V2 the grid mode is set to "automatic" mode as default and switching grid from on to off and vice versa does not work. 4. changing the grid mode from "automatic" to "basic" while file remains open makes grid --> on/off work via menu and as well via shortcut 5. the "basic" mode setting gets lost after changing to another picture file even when AP 2 stays open in between. 6. when you save the picture file after having grid mode set to "basic", the grid mode "basic" is back on reopen of that same file. Thus any other opened picture file is opened in state "automatic" again until you save it in "basic" mode, too. 7. Changed grid colors however are memorized until you change them. Even when AP 2 was closed in between. Is there some other parameter or operation which makes AP 2 to memorize grid mode once it was changed? I do not think, that Serif intended to let me open some 10.000 files in order to save grid mode inside those picture files.

@walt.farrell Congratulations Walt. And now please tell us how you managed to achieve your success. Thank you.