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
