Hi Raphael, RaphaŽl Quinet wrote: > Well, I am still not sure about what was the real source of the > problem mentioned in that bug report.
Quite simply, Photoshop (according to the bug submitter) does not pre-multiply RGB data by the alpha channel when saving, which allows the complete data to be retrieved afterwards. This is perhaps an option, but that was the origin of the problem. The submitter expected the GIMP to do the same thing. > 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 do we - but at load time, we pre-multiplied the RGB values (as prescribed in the standard), so the behind-the-alpha data was destroyed. Actually, without going into details, I think it could be considered correct to do this on save, but to read the data in the file as-is (that is, without pre-multiplication). That is, we assume that this operation was done by the application that created the image, and we read whatever's in the file. Part of the patch I attached to that bug would do this, if it were desirable. > 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. Nope - according to the latest tiff standard I could find, we're unequivocally doing the right thing on save. > It > may be an undocumented extension - TIFF is known to be full of these. Ah - if you say so :) > 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. The fundamental rule that I thinkl we should follow is that modifying any 3rd party or user data should require an explicit action from the user (switching a toggle to optimize the image, for example, or toggling a preference to do alpha pre-multiplying, or somesuch). If the user does not request it, we should not touch his data just because we think that might be what he would expect. > Exposing internal data to the average user means that we would not be > allowed to some of this internal stuff later. Nonesense. Applications change their behaviour all the time - free software projects more than most. If we decide to provide features like layer auto-growing in the future, then we can do so. Saying that one 20 line patch will prevent us from doing something is just wrong. Also, I do not consider the data we're talking about to be internal, or undefined. It is simply data which is not visible in the projection. <snipped very interesting undo brush description> The undo brush sounds like it would be a nightmare to implement and get to act reasonably... Cheers, Dave. -- David Neary, Lyon, France E-Mail: [EMAIL PROTECTED] _______________________________________________ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer