After an evaluation, GNOME has moved from Bugzilla to GitLab. Learn more about GitLab.
No new issues can be reported in GNOME Bugzilla anymore.
To report an issue in a GNOME project, go to GNOME GitLab.
Do not go to GNOME Gitlab for: Bluefish, Doxygen, GnuCash, GStreamer, java-gnome, LDTP, NetworkManager, Tomboy.
Bug 134304 - paste as new adds transparency
paste as new adds transparency
Status: RESOLVED FIXED
Product: GIMP
Classification: Other
Component: General
1.x
Other All
: Normal minor
: 2.4
Assigned To: GIMP Bugs
GIMP Bugs
Depends on:
Blocks:
 
 
Reported: 2004-02-13 09:28 UTC by Olivier Ripoll
Modified: 2005-06-10 14:45 UTC
See Also:
GNOME target: ---
GNOME version: ---


Attachments
A Patch to correct a bug in sparkle.c (355 bytes, patch)
2005-01-01 17:59 UTC, Shlomi Fish
none Details | Review

Description Olivier Ripoll 2004-02-13 09:28:44 UTC
I think "paste as new" adds transparency even if what is copied does not
have any, which results in having the "export" dialog poping up when saving.

Observed on 2.0pre3 on linux (home-built) and 2.0pre2 on WinXP (Jernej
Simoncic build).

steps to reproduce:
1- open a jpeg file (a file with no transparency should be ok, bmp could do
it also)
2- select all (or a part)
3- copy
4- paste as new
5- save as jpeg (bmp also gives the same result)

expected result:
The file gets saved.

actual result:
The export window pops up telling me transparency is not supported for this
file format etc.

Since I try to save in the save format than the original and have never
added transparency in the process, the image should not have acquired
transparency, should it? I find it bothering for me (more clicks, etc.) and
confusing for any newbie ("Why does gimp refuses to save my jpeg which has
no transparent parts?")
Comment 1 Sven Neumann 2004-02-13 14:22:50 UTC
We will need to do quite a few changes to the buffer handling since at
the moment, the alpha channel is added when the copy is made and
buffers are assumed to always have an alpha channel. Perhaps something
for 2.2.
Comment 2 Brion Vibber 2004-07-05 08:58:56 UTC
I've noticed that the pasted image is also always RGB even if the source was grayscale or indexed 
(2.0.1/Linux and 2.1.2[CVS]/Mac OS X).
Comment 3 Sven Neumann 2004-10-24 20:38:20 UTC
Since no work has been done towards this feature, it needs to be postponed for
the next development cycle. Moving from the 2.2 milestone to Future.
Comment 4 Shlomi Fish 2005-01-01 17:59:14 UTC
Created attachment 35340 [details] [review]
A Patch to correct a bug in sparkle.c

This is a patch to correct a problem I found in sparkle.c which I discovered
while comparing the GIMP 1.2 sparkle.c to the GIMP 2.2 one, while trying to get
to the root of the problem with this bug.

Note that it doesn't correct the problem reported here, but it's still a bug.
The problem is that the alpha pixel is taken from the start of the row instead
of from the current pixel.
Comment 5 Sven Neumann 2005-01-02 01:35:31 UTC
Comment #4 was probably meant to go to bug #132145 instead.
Comment 6 Michael Natterer 2005-06-10 14:37:15 UTC
Actually, this is easy to fix, but unfortunately it's not entirely fixable.
It's impossible to keep the buffer flat when copying from a selection,
because that selection may have any shape, be fuzzy.
Comment 7 Michael Natterer 2005-06-10 14:45:35 UTC
Fixed in CVS:

2005-06-10  Michael Natterer  <mitch@gimp.org>

	Fix bug #134304, as far as it's fixable:

	* app/core/gimp-edit.c (gimp_edit_paste_as_new): handle pasting
	buffers without alpha. Also don't uselessly convert all buffers
	to RGB but create an image in the buffer's color space.

	(gimp_edit_extract): call gimp_selection_extract() with
	add_alpha = FALSE.

	* app/core/gimpselection.c (gimp_selection_extract): set add_alpha
	to TRUE if there is a selection, because the selection could have
	any shape.