Delete an adjustment from History

[bill hansen]

In Photo Shop, the History panel shows all the changes which have been made to the image, as it does in AP. But in AP. In PS, I can discard a change by clicking on the History panel and dragging a History item to the trash can. I don't see a way of doing that in AP.  Is there a way to discard a change in AP, other than making sure to do each change on a new, separate layer?

[v_kyr]

See: History panel

Quote

If you click on an earlier state and then make a different change, any states that originally came after it are deleted.

 

[bill hansen]

Thanks - that helps a lot. It's not quite the same as PS, but I can make it work. - Just have to develop a new habit (not as easy to develop new habits as it used to be for me)  :-)    - Bill

[Alfred]

In version 1.7 (currently in public beta) we can use the new “alternate futures” feature:

Quote

• “Alternate futures” for document history have been added. Traditionally, if you roll back the undo history then do something else all your changes after that point are lost. Photo will now display a small branch icon in the history tab when you do this. Pressing that button will cycle between all the different “futures” after that history entry - meaning you will never lose work you have done.

 

[R C-R]

57 minutes ago, Eℓƒяє∂ said:

In version 1.7 (currently in public beta) we can use the new “alternate futures” feature:

Which I assume may be something like Photoshop's "Non-Linear History" option, but I don't know anything about how that works in PS.

BTW, the Affinity Photo 1.7 beta is a customer, not a public, beta.

[Alfred]

44 minutes ago, R C-R said:

BTW, the Affinity Photo 1.7 beta is a customer, not a public, beta.

Oops, yes. I was thinking ‘public’ in the sense of ‘not private’, i.e. not restricted to Serif staff and invited beta testers.

Fixed now.

[bill hansen]

I just tried the suggestion of clicking on the adjustment above the one you want to delete, in the History panel. I think V_KYR was thinking of what happens in the Layers palette, which I already knew about. Deletion from the History palette doesn't work, as far as I can tell, though it does work in Photo Shop. It's important, because some adjustments, like Denoise, don't show up in the Layers palette, so there's no way to adjust Denoise. If you've overdone Denoise, you're stuck, and must start over.Maybe the "Alternate futures" feature in v. 1.7 will work.

I have played around with v 1.7 a little, mainly because its noise reduction is rumored to be much better than it was in 1.6. So far, I'm not convinced about Denoise in AP. It works, but Topaz is much better IMO. AS for "Alternative Futures", I don't see it in my copy of 1.7.0.188   I guess the beta is beyond my technical abilities. I'd better stick to Photo Shop for now.

[R C-R]

"Alternate Futures" is implemented as branch icons on History panel entries that looks like this:  It works by cycling the History panel through all the different 'futures' after that entry when you click on it.

But you can't arbitrarily delete individual intermediate entries with it, in part I suppose because some entries could not exist without others that precede it, like the entries that paint on or otherwise modify a new pixel layer added to the document. If the entry that created that pixel layer could be deleted, there can be no 'future' where that layer will exist & thus nothing to modify on it.

I suppose that is what the branch icon is intended to suggest -- you can't jump directly between different branches of the history 'tree' but instead must return to where a different branch begins to move along it into that branch's future. IOW, the path of history through time can be nonlinear in the sense that it does not have to follow a single path from past to future, but each alternate path is still dependent on the path(s) that led to it.

[JimmyJack]

This is all the more reason to have a proper contemporary non-linear NODE based UI !!!

Both Designer and Photo are node based under the hood anyway.
The decision to go with an old school layer based interface (because of it's familiarity) in order to grab an initial user base was a HUGE missed opportunity.... imho.

Affinity could have leapfrogged over the "competition" and led the way.
Now it's just playing catchup... along with you know who.

Yeah, I know nodes can be scary at first and may take some time to get used to.
At least give those of us who are familiar (and get how powerful they are) the option to enter a node-mode!! 

[R C-R]

21 minutes ago, JimmyJack said:

At least give those of us who are familiar (and get how powerful they are) the option to enter a node-mode!! 

How would that eliminate the problems of past-to-future dependencies? Think of it like the classic time travel paradox of going back in time & killing someone in your family tree so you never could have been born to go back in time to do that.

How would a node-based UI resolve that?

[JimmyJack]

3 hours ago, R C-R said:

How would that eliminate the problems of past-to-future dependencies? Think of it like the classic time travel paradox of going back in time & killing someone in your family tree so you never could have been born to go back in time to do that.

How would a node-based UI resolve that?

Right now the history panel does what you're describing. If you delete a step everything after is goes with it. If you use the alternate timeline everything comes back. You have two options.

With nodes you CAN go "back in time" (...without a history panel. Actually, time kinda doesn't exist.) and change things and that change will cascade through the rest of the node tree.
I'm not suggesting you can delete something and have it stay too... this isn't Schrodinger's Denoise .
In the OPs situation, you can replace the Denoise with a new Denoise, or replace it with something else, or add a modifier to it. And if you want that modifier to affect something else 10 "layers" away, well you can just jump over everything and add another connection there. One change in one modifier will change both (xN) elements.... or anything else you want to do, ad nauseam.

In terms of the layer stack itself a node tree would add unbelievable flexibility and remove a lot of potential redundancy. It's a whole different world inside a node editor. It's a different way of thinking. That's probably part of the reason why it wasn't immediately implemented. People usually freak out when first confronted by it.

[R C-R]

9 hours ago, JimmyJack said:

With nodes you CAN go "back in time" (...without a history panel. Actually, time kinda doesn't exist.) and change things and that change will cascade through the rest of the node tree.

Except that it is obvious from your attachment that it isn't really a node "tree." Conceptually, it resembles the layout of an old school analog audio synthesizer, with functional modules with various inputs & outputs that can be patched together in myriad ways to produce a nearly infinity variety of sounds. That is what makes the concept so powerful.

But it is also obvious from your attachment that as more nodes & connections are added, it could turn into the virtual equivalent of what is sometimes referred to as a "spaghetti farm" in the analog world -- an unstructured tangle of interconnections that can quickly become a nightmare to modify without tearing it apart & starting over.

Of course, there are ways to avoid this, but the real issue is how to do that while still retaining enough of a structural framework of some kind to keep it manageable as it is scaled up to the equivalent of a conventional document structure with what could be hundreds of layers grouped & nested in countless ways.

Any thoughts on how you would like to see that done in Affinity?

[JimmyJack]

12 hours ago, R C-R said:

Of course, there are ways to avoid this, but the real issue is how to do that while still retaining enough of a structural framework of some kind to keep it manageable as it is scaled up to the equivalent of a conventional document structure with what could be hundreds of layers grouped & nested in countless ways.

Any thoughts on how you would like to see that done in Affinity?

Ha! Yeah it can get busy. But I still think it's better than a huge list. And of course infinitely more powerful.
You can be more organized if you try....

Thoughts? I'd like a system where one could choose to use nodes or not (a simple file may have no real need for nodes....). Or even mix and match some elements.
As far as the editor itself, I'd be happy with any kind of Node Editor from the past 1, 2, 3 or even 4 years. 
It's important to have a good Group (sometimes aka Compound) Node..... that cuts down on a lot of clutter.
And maybe a grid with some kind of snapping system and a "nudge/clean up" function.

Most importantly though is that when you get used to it, it becomes second nature.... Just ask Cypher.

 

[v_kyr]

Well I would prefer 3D "Cone Trees" based presentations instead!

However, overall those linked lists from Davinci resolve and some other tools are like what most OO Modeling tools and some other 3D Engines do offer for representation purposes. - The point is what is most flexible to use, gives good information overview even for complex structures and is still easy to manage for people and end users.

 

[R C-R]

24 minutes ago, JimmyJack said:

Ha! Yeah it can get busy.

Which I think is a problem for graphic apps like Affinity that are intended to work well on various sized displays, including laptops with not a lot of screen space to spare for complex node maps. For that matter, just displaying either of your example maps on my 27" iMac in a window zoomed to the max is still way too small to do much with, & of course that leaves no space for a document view.

FWIW, way back when I was using OS 9 on a PPC Mac, I played around with an experimental software app that emulated an audio synthesizer with a module & patch cord visual layout that was very similar to your node maps. I don't remember all the details but you could zoom in to get a larger view of an area of the map & when drawing a new patch connection it would auto-scroll so it was reasonably workable in that respect, even with very complex layouts.

But, the reason it was workable was the 'output' was to audio, & there was a scrub bar like with animation or other audio software, so you could hear the changes when you made them. The same would not be true for graphics editing software -- you would have to have enough screen space available for a reasonably sized 'live' view of the document itself and the map for this to be very useful.

[JimmyJack]

@R C-R 
I'm not sure what zooming in on my screen grabs do ?

Of course any decent node editor will have zoom and pan capabilities.
If screen real estate is a deal breaker don't use it. Doesn't bother me. I personally know plenty of people who edit movies on less than monstrous monitors (or even on laptops).
but, also.... The node editor can be an overlay on the image itself. The entire screen could be the image with the nodes occupying any portion of the screen superimposed on top. A simple key tap could hide and recover. 

My Gawd @v_kyr ! What program is that??!! More power to ya!!

[v_kyr]

18 minutes ago, JimmyJack said:

My Gawd @v_kyr ! What program is that??!!  

A pretty old one Cat-a-Cone: Visualization of a search in the database "Medline" (see for example in german "Wunderkammer Cyberspace?"). There are a bunch of old techniques and papers for 3D visualization of information systems and user interfaces (here a PDF paper about an UI) already available, some of these are good for presenting more complex structured informations.

[R C-R]

1 hour ago, JimmyJack said:

If screen real estate is a deal breaker don't use it. Doesn't bother me.

What would bother me a lot is if developing something like this (that I doubt many users would use, no matter how powerful they made it) detracted from the effort to fix all the problems currently in the apps or implementing the remaining items on the roadmaps; or in any way negatively affected performance, minimum system requirements, memory efficiency, or anything else that makes the Affinity apps less useable than they are now.

To me, this is something that should be a core feature of specialized apps built from the ground up for that purpose, not for general purpose graphics editing apps. 

[Frozen Death Knight]

On 12/26/2018 at 11:58 PM, JimmyJack said:

This is all the more reason to have a proper contemporary non-linear NODE based UI !!!

Both Designer and Photo are node based under the hood anyway.
The decision to go with an old school layer based interface (because of it's familiarity) in order to grab an initial user base was a HUGE missed opportunity.... imho.

Affinity could have leapfrogged over the "competition" and led the way.
Now it's just playing catchup... along with you know who.

Yeah, I know nodes can be scary at first and may take some time to get used to.
At least give those of us who are familiar (and get how powerful they are) the option to enter a node-mode!! 

I really don't see the point of having an image editing program completely built around a node system, especially in regards to the layers. Just because using layers is an old way of doing things is not much of an argument, especially if the system already works just fine, which it currently does. If it isn't broken, don't fix it. There are far more pressing matters that could be addressed than completely reworking a feature that is industry standard and widely accepted by pretty much every, single image editing software out there.

[JimmyJack]

24 minutes ago, R C-R said:

To me, this is something that should be a core feature of specialized apps built from the ground up for that purpose, not for general purpose graphics editing apps. 

HAHA LOL. Affinity, built from the ground up, IS node based. The skin on top that we have now is a construct  to conform to old school thinking.

[R C-R]

5 minutes ago, JimmyJack said:

Affinity, built from the ground up, IS node based.

How could you possibly know if it is, or any of the details of whatever you mean by "node based"?

[JimmyJack]

27 minutes ago, R C-R said:

How could you possibly know if it is, or any of the details of whatever you mean by "node based"?

From moderator...

"Both Photo and Designer are effectively node-based internally. We chose to expose the object model to the user as a traditional "layer stack" because that's what people expect.."

https://forum.affinity.serif.com/index.php?/topic/15873-coming-2016-32bit-hdr-editing-sneak-preview/&do=findComment&comment=81085

[R C-R]

I saw that when it was posted back in 2016, but I still wonder what "effectively node-based internally" really means, if it is still as true after all the 'refactoring' for 1.7, how it could be 'exposed' in a useful way, if enough users would actually use it to justify the development effort, & if it really makes good business sense even to try.

[JimmyJack]

Give me a break. Now it's a business decision? This is where I started!! You're a moving target R C-R . I'm out.

[R C-R]

Just now, JimmyJack said:

Give me a break. Now it's a business decision? I'm out.

When would it ever not be a business decision???