On Wed, 10 Dec 2003 16:13:48 +0100, Dave Neary <dneary@xxxxxxx> 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. -Raphaël
