RE: aperture
- From: David Moore <dcm MIT EDU>
- To: dmgerman uvic ca
- Cc: Philippe Desaulniers <philippe desaulniers averna com>, F-Spot <f-spot-list gnome org>
- Subject: RE: aperture
- Date: Thu, 20 Oct 2005 18:01:19 -0400
I've given this type of thing some thought as well. What we really need
is a new type of photo editing program written from scratch, that throws
out all the previous conventions. As far as I am concerned, both
Photoshop and Gimp are wrong in their user interface conventions.
(Maybe Aperture or iPhoto get it right, but I haven't looked at them).
To solve the problem you mention below, it shouldn't save the history,
rather, it should make _every_ operation a layer (similar to photoshop's
"adjustment layers"). If you want to draw, it's a new transparent layer
on which you draw. You can _never_ draw on an existing layer (although
you could modify a previous "draw layer").
Another example: Opening a RAW file would not do a conversion, rather,
it would create the following stack of layers automatically for you:
1. RAW file source
2. Bayer interpolation
3. White balance
4. ... <-- layers of your choice go here to edit the image
5. Sharpening
6. Gamma correction
7. Output
Layers 2,3,5,6 would each have "knobs" that you can tune to your liking.
And even if you added more layers in between (such as drawing), the
output would automatically be updated to reflect any changes in any
layer after the fact.
You could then just save a copy of the layer stack 2-6 and apply it to
any other image.
If I had lots of free time, I'd start writing this hypothetical
application myself, but unfortunately I don't. Throw in HDR support and
color-management and you'd have a real killer app as far as I'm
concerned.
-David
On Thu, 2005-10-20 at 11:25 -0700, Daniel M. German wrote:
> The problem of saving histories is that they are actions that are
> destructive of previous actions (for example, you create a layer,
> draw over it, and then destroy it). In this case you don't want to
> save every actions, because it will lead to huge files. This might
> not be a trivial problem.
>
[
Date Prev][
Date Next] [
Thread Prev][
Thread Next]
[
Thread Index]
[
Date Index]
[
Author Index]