On Wed, 10 Dec 2003 16:13:48 +0100, Dave Neary <[EMAIL PROTECTED]> wrote:
> In any case, masks and alpha channels are also used to hide data across 
> sessions for several file formats (eg. png), and we have ven had a bug 
> report against the GIMP 
> (http://bugzilla.gnome.org/show_bug.cgi?id=82882) because someone 
> expected this behaviour from the tiff plug-in (apparrently this is 
> provided by other programs).

Well, I am still not sure about what was the real source of the
problem mentioned in that bug report.  It looks like the GIMP uses
pre-multiplied alpha when saving this type of TIFF files (and it seems
to be correct, according to the standard that you quoted) while some
other software does not pre-multiply by alpha.  According to the
second comment from the reporter, it looks like Photoshop is able to
decode both types of images correctly (with and without pre-
multiplication) so I suspect that the real problem comes from some
exotic option that we (or libtiff) do not use and that would allow us
to save the image with full RGBA information.  There is probably a
flag that we do not parse and do not set that would allow this.  It
may be an undocumented extension - TIFF is known to be full of these.

> > 2) For the pixels that have been obtained from an external source,
> >    then the "hiding" concept does not fit because the RGB data is
> >    undefined.
> This is where we start to voilently diverge :) I disagree that this is 
> the case. It may be considered to be the case in some specific 
> circumstances, but in general, we should not destroy data, IMHO.

Well, I'd rather be non-violent...  ;)  Of course, we should not
destroy data if we have no good reason to do it.  On the other hand,
we should not lock ourselves in a situation that would prevent us from
destroying this data if that could bring other advantages.

Exposing internal data to the average user means that we would not be
allowed to some of this internal stuff later.  Note that it may be
different if we talk about advanced users: they can fiddle with
internal data because they know a bit of what is under the hood and
they also know that the implementation might change in the future.

> As a matter of interest, how would an undo brush work? I'm having 
> trouble getting my head around the idea.

We don't have to implement this in the same way as Photoshop or other
programs do, but the basic idea would be something like this:
- You select the undo brush with a suitable brush size, shape and
  other parameters.
- You select one of the steps in the undo history.
- You start painting with your brush in the image.  The area covered
  by your brush is replaced by the corresponding area in the older
  version of the image.  So if you erased something by mistake of if
  you were too generous while painting along some edge, you can easily
  restore it.  You can restore some small details or do a partial
  merge by selecting the appropriate size and opacity of the brush.

Note that I am not sure about the implementation details because I
have never used it.  I only read some descriptions of how it works and
how it can be very useful for making small corrections to an image.
There are many details that would have to be solved before
implementing this.  For example, we should make sure that the undo
step from which we copy pixels is not discarded from the undo history
even if we paint with the undo brush in several strokes.  Also, how do
we select the correct source pixels in the undo history if the image
was scaled, rotated or translated?  What about the undo steps
consisting in the removal of a layer?  We should probably not allow
all undo steps to be selected as the source of the pixels for the undo
brush.  So there are still a number of open questions, but the undo
brush looks like a very useful feature.


Gimp-developer mailing list

Reply via email to