On Tue, 20 Feb 2001, Sven Neumann <[EMAIL PROTECTED]> wrote:
> [EMAIL PROTECTED] (Raphael Quinet) writes:
> > Consider the following cases, which should all produce a file with
> > transparency, if the File->Save plug-ins were working as the user
> > would expect:
> > - Create a new image, use Image->Canvas Size to increase the size of
> >   the canvas (some transparent areas appear), then save as PNG.
> IIRC, changing the Canvas Size does not alter the saved result at all
> since most file plug-ins save the current layer, not the whole image. 
> I don't see why the user would expect an alpha channel here.

Because most new users would expect this to happen.  When you are
familiar with the insides of the Gimp, you know that "saving an image"
actually means "saving the current layer" if and only if you selected
a single-layer image format (e.g., PNG, JPEG, TGA, ... but not XCF).
But this goes against the principle of least surprise and most users
who are not familiar with the insides of the Gimp consider this as a

For example, take a look at bug #23610: it is clear that the user
expected that resizing the canvas of his 800x654 PNG image to 800x600
would result in an image that is 800x600.  Instead, he got an image
that was identical to the original one.  Granted, we all know that the
current version of the Gimp behaves like that, because only the
current layer was saved, ignoring the settings that are associated
with the image but not with the layer.  We all know that he should
have used the Crop tool or flattened the image or (if the PNG image
had some transparent parts) merged the image with a new transparent
layer that had the same size as the canvas.  But the behavior that he
observed is not very intuitive.

If the canvas size is different from the layer size (in a single-layer
image), it would be better to trigger the Export dialog and ask the
user if he/she wants to:
- save only the current layer,
- flatten the image first, or
- clip the image (merge the current layer with a transparent layer that
  has the same size as the canvas, which is useful if there are some
  transparent areas that should be preserved).
That would solve the problems like the one described in #23610.  It
would work when the layer is larger or smaller than the canvas.

> > - Create a new image, use the Move tool to move a part of the layer
> >   out of the canvas, then save the result as TGA or TIFF.
> Same reasons apply here.

Same comments as above.  But in addition, this gets very interesting
when you save as PNG, because PNG takes the layer offset into account
but ignores the canvas size.  Try the test case (2a) in bug #51114.
This will give you the most surprising results: an image that has the
correct offset but the wrong size.  Again, the results can easily be
explained if you know how the Gimp works internally and what options
are supported by the PNG format.  But I do not think that anybody
would really expect the results that you get by following the steps
described in (2a).  Compare the saved file with the image as it was
before saving it.

Link to the bug report: http://bugzilla.gnome.org/show_bug.cgi?id=51114

> > - Create a new image, use the Opacity slider in the L,C&P dialog to
> >   make it partially transparent, then save as PNG.
> Correct, see my notes above.
> > Wouldn't this be another reason to get rid of the default RGB-only
> > background layer?
> Yes. But I don't think we should always add the alpha channel. Just 
> do it automatically as soon as there is more than a single layer in 
> the image.

Yes, that would be a solution.  As a matter of fact, I went back to
the archives of this mailing list and I saw a discussion that I
initiated in May 2000, with the subject ``Is "Add alpha channel"
really necessary?''.  The conclusion was that the alpha channel should
be added automatically.  And Gary Osgood said: "I imagine Mitch is
coding it already, ;)".

However, if you look at the messages that were posted on the 16th of
May, you will see that my opinion was that the alpha channel should be
added as soon as a second layer is created, while Gary thought that it
would be better to keep the background layer "special" until the user
clicks on the up/down arrows to move another layer below the
background layer.

When I posted my first message today (before re-reading this old
thread), I thought that it would be better to always add an alpha
channel to all images.  But the arguments that I posted last year
convinced me that I was right at that time.  ;-)

> > Also, the file plug-ins would have to be modified to check if the
> > alpha channel is empty or not before saving the image.  This could be
> > another option in the user preferences: "automatically strip an empty
> > alpha channel when saving an image" (default would be ON).  There could
> > be another option, similar to the one used in the "Clear Alpha" script:
> > "minimum value needed to declare an alpha channel non-empty" (default
> > would be around 10%, or maybe 0).
> IMHO unnecessary since the user can always use Flatten to get rid of 
> the alpha channel before saving.

Right.  Ignore that brain fart.  ;-)


Gimp-developer mailing list

Reply via email to