4 ms·

1 - automatically save a version history and completely remove the need to think ‘have I saved this’. Same goes for all editors.

chongli 8y ago
Yes. Let me join in the fun: 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.
- wildpeaks 8y ago
  At least they have been moving towards Node for the scripting part (Photoshop even ships with Node, you can make panels in HTML5, even use WebGL). Although I wish the documentation wasn't just PDF files you can't copy/paste from, not an ideal way to provide code snippets.
- gmueckl 8y ago
  Have you estimated the menory requirements for what you are proposing? Each brush stroke would need to store some image data for this to work. Just storing e.g. pen movement and rendering the result on the fly will likely not recreate the same result in an uodated version of the program, altering the image that the user created. Also, reopening complex files would take longer than users are willing to tolerate. The undo stack (which internally is pretty much an implementation of non-destructive editing) is about as far as you can bring the concept realistically. 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.
  - chongli 8y ago
    Each brush stroke would need to store some image data for this to work. 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.
    - gmueckl 8y ago
      Google Tilt Brush saves brush on strokes. It takes roughly a minute to open a moderately complex sketch sketch in that program. 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.
      - chongli 8y ago
        Well, what if your image editor used an interpreter and the nondestructive edits were recorded in the document as scripts which, when replayed, construct that layer of the image. That way you can change the application all you want as long as you don't break the interpreter. As for Google Tilt Brush, well that's just a failure to use proper caching.
        gmueckl 8y ago
        Proper caching brings us back to the question of memory usage that I started out with. For the record, I don't think that Tilt Brush can be accused of a failure to cache properly. It need to recreate sketched 3d models for VR and I thibk there is some kind of LOD stuff going on when creating the final geometry, based on the performance of the computer it is running on. 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.

chongli 8y ago

Yes. Let me join in the fun: 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.

wildpeaks 8y ago
At least they have been moving towards Node for the scripting part (Photoshop even ships with Node, you can make panels in HTML5, even use WebGL). Although I wish the documentation wasn't just PDF files you can't copy/paste from, not an ideal way to provide code snippets.
gmueckl 8y ago
Have you estimated the menory requirements for what you are proposing? Each brush stroke would need to store some image data for this to work. Just storing e.g. pen movement and rendering the result on the fly will likely not recreate the same result in an uodated version of the program, altering the image that the user created. Also, reopening complex files would take longer than users are willing to tolerate. The undo stack (which internally is pretty much an implementation of non-destructive editing) is about as far as you can bring the concept realistically. 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.
- chongli 8y ago
  Each brush stroke would need to store some image data for this to work. 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.
  - gmueckl 8y ago
    Google Tilt Brush saves brush on strokes. It takes roughly a minute to open a moderately complex sketch sketch in that program. 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.
    - chongli 8y ago
      Well, what if your image editor used an interpreter and the nondestructive edits were recorded in the document as scripts which, when replayed, construct that layer of the image. That way you can change the application all you want as long as you don't break the interpreter. As for Google Tilt Brush, well that's just a failure to use proper caching.
      - gmueckl 8y ago
        Proper caching brings us back to the question of memory usage that I started out with. For the record, I don't think that Tilt Brush can be accused of a failure to cache properly. It need to recreate sketched 3d models for VR and I thibk there is some kind of LOD stuff going on when creating the final geometry, based on the performance of the computer it is running on. 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.