> but it _is_ very similar to PS in design and functionality
Thankfully that didn't stop Serif with Affinity Photo. The user interfaces and tools are so similar many tutorials don't even need modification.
Thankfully that didn't stop Serif with Affinity Photo. The user interfaces and tools are so similar many tutorials don't even need modification.
There are a lot of parts of Photoshop which could be radically improved if Adobe weren’t constrained by needing to preserve existing customer workflows from circa 1995 and build off decades of legacy code / organizational inertia. Most of the low-level decisions in Photoshop are based on academic research from the 1970s, reimplemented in the early 1990s to match mid-range computer workstations and typical images of that time.
Many new image editors have basically zero thought put into design or core image processing infrastructure, and are just exact copies of Adobe’s ideas, without considering that computers and imaging have changed dramatically in the past 2 decades.
(To be fair, coming up with new ideas and then polishing them to the point they are ready for customers is really hard: it takes vision, cross-disciplinary expertise, new research work, multiple attempts at implementation when some ideas don’t work out, integration effort fitting ideas together, etc. Clones are a lot easier.)
2 - every operation, every brush stroke, should be nondestructive, stored on automatic layers, and always adjustable.
3 - the rendering pipeline should be built from the ground up to support the nondestructive workflow on modern hardware. This means aggressive caching of layers with GPU compositing throughout.
4 - a full commitment to open data formats. Since a nondestructive workflow requires storing all of the instructions for every edit, these should be save-able in an open, human-readable format such as JSON. This would open the doors to scripting the editor with external tools, with the nondestructive editing instructions coalescing into a standard API.
Although I wish the documentation wasn't just PDF files you can't copy/paste from, not an ideal way to provide code snippets.
Non-destructive workflows also have a huge maintenance problem: you can never again touch code that is involved in the creation of the final result after it has been released because it might break the user's files. It is not just the loading and storing part, but the whole backend can never be evolved in a reasonable way without breaking backward compatibility. After a while you sit on a pile of code for legacy operators and data models that you need to support and stops you from doing meaningful development.
I love non-destructive editing in many cases, but I also have some experiences with implementing that concept and this has shown me how constraining it is and how much effort it takes.
No, brush strokes would be stored as paths that simply record the input information needed to reproduce what the artist did with her mouse or stylus.
I hear you about the issue of breaking changes though. I think it takes real discipline to develop a format that's adaptable and with the capability to let you migrate files without visible changes. It would take one hell of a test suite though.
The only way to not change the output is to match the the already released operators exactly. This is almost impossible unless you freeze the code for each operation after it has been released originally.
As for Google Tilt Brush, well that's just a failure to use proper caching.
And yes, any descriptions of nondestructive edits is by its nature a script that needs to be replayed by an interpreter to get the final state of the document. No matter the level at which you introduce the interpreter, you cannot upgrade it without risk to backwards compatibility to existing documents.
And if you you want the script language to be low level enough so that the implementations of your operators need to be dumped into the document, then you need to (a) write about half of your program in said scripting language and (b) end up duplicating that in every dicument that is created.
Oh, so Tilt Brush is 3D? So it's not at all comparable to a 2D image editor. I don't see how proper caching of a fully nondestructive editor should use any more space than a Photoshop document with a ton of layers. In fact, I think it could use a lot less, since Photoshop wastes tons of space when you duplicate source images in order to build up filtered layers with masks and so on. A nondestructive editor could save the space by not duplicating those source images so much.
And if you you want the script language to be low level enough so that the implementations of your operators need to be dumped into the document, then you need to (a) write about half of your program in said scripting language and (b) end up duplicating that in every dicument that is created.
Yes, this is what I had intended. But I don't think it's as bad as you say. You don't need to dump the bytecode (or equivalent) of your entire editor into every document, you only need to include the bytecode needed to reconstruct each of the edits made by the artist.
The editor itself could even include the source code of all its operators and let the artist modify it as she goes. It would be like the Emacs of image editors!
I am not going to create a full model to estimate memory usage and of the different designs. It is however clear that a nondestructive approach is more computationally heavy in principle because it will always rerun the same operations more often than a destructive one. And all these times do add up. An operation that takes 100ms after a click or keypress is perceived as practically instant. But 100 of these take 10 seconds. And there are operations in Photoshop that a lot longer than that.
The main problem of the Affinity stuff is a lack of integration with professional niches and functionality that pros need for daily bread & butter work. E.g. not having an easy way to mock products (smart objects) renders it already unusable for most professional graphic designers. Instead of using the commonly used HSV color picker like in Adobe apps or Sketch, they go with HSL which isn't as intuitive. Many "small details" like that..
The devs seem to focus on overall functionality, specs and performance, not workflow specific functionality that makes tasks easier. The UI looks great, but is awkward to use.
They seem to be more concerned about being perceived as alternative to Adobe products than actually being an alternative.
It is a tool that is more than powerful enough for the photo-editing needs of almost everyone, and it costs a tiny fraction of Adobe's offering. At least there are a couple of companies offering some competition these days.
Also, recent versions of Affinity do support HSV mode too, afaik.