all messages for Emacs-related lists mirrored at yhetil.org
 help / color / mirror / code / Atom feed
* PNG image files with alpha channel
@ 2008-05-08  4:46 Miles Bader
  2008-05-08 11:48 ` Chong Yidong
  0 siblings, 1 reply; 13+ messages in thread
From: Miles Bader @ 2008-05-08  4:46 UTC (permalink / raw)
  To: emacs-devel

Is Emacs supposed to properly handle an alpha channel in a PNG file?

I vaguely recall that it used to do something halfway reasonable (even
if just merging in the default bg color), but now it seem to simply
ignore an alpha channel.

E.g., using default settings, with a white background, do:

   (insert-image (create-image "image-with-alpha.png"))

[The create-image :background parameter seems to have no effect either.]


If you don't have an alpha-channel-bearing image, try this:

   http://download.savannah.gnu.org/releases/emacs/icons/emacs5-256.png

The "background" around the sphere has an alpha channel that's mostly zero.

Thanks,

-Miles

-- 
Politeness, n. The most acceptable hypocrisy.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08  4:46 PNG image files with alpha channel Miles Bader
@ 2008-05-08 11:48 ` Chong Yidong
  2008-05-08 12:05   ` Jason Rumney
  0 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2008-05-08 11:48 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel

Miles Bader <miles.bader@necel.com> writes:

> Is Emacs supposed to properly handle an alpha channel in a PNG file?

Yeah.  See the png_load function in image.c.

> I vaguely recall that it used to do something halfway reasonable (even
> if just merging in the default bg color), but now it seem to simply
> ignore an alpha channel.

It merges in the :background spec if there is one; otherwise, it uses
the frame background color.

> If you don't have an alpha-channel-bearing image, try this:
>
>    http://download.savannah.gnu.org/releases/emacs/icons/emacs5-256.png
>
> The "background" around the sphere has an alpha channel that's mostly zero.

Hmm, I'm not sure what's wrong with this image.  For an example of a png
image with alpha background rendered correctly in Emacs, see

http://www.w3.org/Graphics/PNG/alphatest.png




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08 11:48 ` Chong Yidong
@ 2008-05-08 12:05   ` Jason Rumney
  2008-05-08 15:02     ` Miles Bader
  0 siblings, 1 reply; 13+ messages in thread
From: Jason Rumney @ 2008-05-08 12:05 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel, Miles Bader

Chong Yidong wrote:
> Hmm, I'm not sure what's wrong with this image.  For an example of a png
> image with alpha background rendered correctly in Emacs, see
>
> http://www.w3.org/Graphics/PNG/alphatest.png
>   

Merely loading it into Gimp and saving it seems to be enough to fix the 
problem (even with the options "Save background color" and "Save color 
values from transparent pixels" ticked). So it must be something in the 
details of how Gimp saves transparency info vs the software Miles used.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08 12:05   ` Jason Rumney
@ 2008-05-08 15:02     ` Miles Bader
  2008-05-08 15:18       ` Jason Rumney
  0 siblings, 1 reply; 13+ messages in thread
From: Miles Bader @ 2008-05-08 15:02 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Chong Yidong, emacs-devel

Jason Rumney <jasonr@gnu.org> writes:
>> Hmm, I'm not sure what's wrong with this image.  For an example of a png
>> image with alpha background rendered correctly in Emacs, see
>>
>> http://www.w3.org/Graphics/PNG/alphatest.png
>
> Merely loading it into Gimp and saving it seems to be enough to fix the
> problem (even with the options "Save background color" and "Save color
> values from transparent pixels" ticked). So it must be something in the
> details of how Gimp saves transparency info vs the software Miles used.

As far as I can tell, it's a valid alpha channel -- firefox displays it
"correctly", as do all the image-display programs I've tried.

I wrote the software that wrote the image, so I have some handle on what
it's doing.  It uses libpng to do the actual writing (and reading),
which is the same library Emacs uses.

Perhaps there's some header info that emacs wants which isn't there?

I write the header like:

  png_set_IHDR (libpng_struct, libpng_info, width, height,
                8, PNG_COLOR_TYPE_RGB_ALPHA, PNG_INTERLACE_NONE,
		PNG_COMPRESSION_TYPE_DEFAULT, PNG_FILTER_TYPE_DEFAULT);
  png_set_gAMA (libpng_struct, libpng_info, gamma_correction);

confusing...

[My software also reads back the alpha info with no problem.]

-Miles

-- 
Egotist, n. A person of low taste, more interested in himself than in me.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08 15:02     ` Miles Bader
@ 2008-05-08 15:18       ` Jason Rumney
  2008-05-08 15:39         ` Miles Bader
  2008-05-08 23:47         ` James Cloos
  0 siblings, 2 replies; 13+ messages in thread
From: Jason Rumney @ 2008-05-08 15:18 UTC (permalink / raw)
  To: Miles Bader; +Cc: Chong Yidong, emacs-devel

Miles Bader wrote:

> Perhaps there's some header info that emacs wants which isn't there?
>
> I write the header like:
>
>   png_set_IHDR (libpng_struct, libpng_info, width, height,
>                 8, PNG_COLOR_TYPE_RGB_ALPHA, PNG_INTERLACE_NONE,
> 		PNG_COMPRESSION_TYPE_DEFAULT, PNG_FILTER_TYPE_DEFAULT);
>   png_set_gAMA (libpng_struct, libpng_info, gamma_correction);
>   

Is there any program that can dump a PNG header in some readable format, 
so we can compare yours with the image that Gimp saves?

Or maybe someone needs to step through the PNG display code in Emacs, 
and see where it (or libpng) makes the wrong decision.





^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08 15:18       ` Jason Rumney
@ 2008-05-08 15:39         ` Miles Bader
  2008-05-08 15:51           ` Jason Rumney
                             ` (3 more replies)
  2008-05-08 23:47         ` James Cloos
  1 sibling, 4 replies; 13+ messages in thread
From: Miles Bader @ 2008-05-08 15:39 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Chong Yidong, emacs-devel

Jason Rumney <jasonr@gnu.org> writes:
>>   png_set_IHDR (libpng_struct, libpng_info, width, height,
>>                 8, PNG_COLOR_TYPE_RGB_ALPHA, PNG_INTERLACE_NONE,
>> 		PNG_COMPRESSION_TYPE_DEFAULT, PNG_FILTER_TYPE_DEFAULT);
>>   png_set_gAMA (libpng_struct, libpng_info, gamma_correction);
>
> Is there any program that can dump a PNG header in some readable format,
> so we can compare yours with the image that Gimp saves?
>
> Or maybe someone needs to step through the PNG display code in Emacs,
> and see where it (or libpng) makes the wrong decision.

Actually I realized that while my software wrote the original image,
those "*-256.png", etc, images are decimated versions that I created
using imagemagick, with "convert -resize ...".

Upon looking closer, I see on very odd attribute:  while the original
image I wrote was RGBA, 8-bits per channel, the decimated versions
written by imagemagick are RGBA, 16-bits per channel...  The Emacs
PNG-reading code asks libpng to convert 16-bit-per-channel images to
8-bits per channel, but as such images are fairly rare, it may be that
libpng doesn't do it correctly.

If I open the original RGBA 8-bits per channel image with Emacs, indeed,
it handles the alpha-channel correctly.

I did step through the code, BTW, and as far as I can tell, Emacs is
doing the correct things.

So the problem may in fact be something with the libpng 16-to-8-bit
conversion code...

[I have no idea why imagemagick creates 16-bit-per-channel output images
from 8-bit-per-channel input images; offhand it seems like a bad idea as
16-bit support is probably less widespread...]

-Miles

-- 
Idiot, n. A member of a large and powerful tribe whose influence in human
affairs has always been dominant and controlling.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08 15:39         ` Miles Bader
@ 2008-05-08 15:51           ` Jason Rumney
  2008-05-08 18:19           ` Chong Yidong
                             ` (2 subsequent siblings)
  3 siblings, 0 replies; 13+ messages in thread
From: Jason Rumney @ 2008-05-08 15:51 UTC (permalink / raw)
  To: Miles Bader; +Cc: Chong Yidong, emacs-devel

Miles Bader wrote:
> So the problem may in fact be something with the libpng 16-to-8-bit
> conversion code...
>   

We may need to explicitly tell it to preserve alpha when it does this 
transformation. Gimp must do something similar, as it only supports 8 
bits per channel internally, and it displays the transparency OK.






^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08 15:39         ` Miles Bader
  2008-05-08 15:51           ` Jason Rumney
@ 2008-05-08 18:19           ` Chong Yidong
  2008-05-09  1:00           ` Chong Yidong
  2008-05-09  2:35           ` Chong Yidong
  3 siblings, 0 replies; 13+ messages in thread
From: Chong Yidong @ 2008-05-08 18:19 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel, Jason Rumney

Miles Bader <miles@gnu.org> writes:

> Upon looking closer, I see on very odd attribute:  while the original
> image I wrote was RGBA, 8-bits per channel, the decimated versions
> written by imagemagick are RGBA, 16-bits per channel...  The Emacs
> PNG-reading code asks libpng to convert 16-bit-per-channel images to
> 8-bits per channel, but as such images are fairly rare, it may be that
> libpng doesn't do it correctly.
>
> If I open the original RGBA 8-bits per channel image with Emacs, indeed,
> it handles the alpha-channel correctly.
>
> I did step through the code, BTW, and as far as I can tell, Emacs is
> doing the correct things.
>
> So the problem may in fact be something with the libpng 16-to-8-bit
> conversion code...

One possibility is that libpng's png_set_strip_16 function only strips
the RGB channels down to 8 bits, while keeping the alpha channel at 16
bits.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08 15:18       ` Jason Rumney
  2008-05-08 15:39         ` Miles Bader
@ 2008-05-08 23:47         ` James Cloos
  2008-05-09  0:43           ` Miles Bader
  1 sibling, 1 reply; 13+ messages in thread
From: James Cloos @ 2008-05-08 23:47 UTC (permalink / raw)
  To: Jason Rumney; +Cc: Chong Yidong, emacs-devel, Miles Bader

>>>>> "Jason" == Jason Rumney <jasonr@gnu.org> writes:

Jason> Is there any program that can dump a PNG header in some readable
Jason> format, so we can compare yours with the image that Gimp saves?

Yes.  ESR's Sng converts between binary png files and a sexp notation.

Grab it at:

http://sng.sf.net

-JimC
-- 
James Cloos <cloos@jhcloos.com>         OpenPGP: 1024D/ED7DAEA6




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08 23:47         ` James Cloos
@ 2008-05-09  0:43           ` Miles Bader
  0 siblings, 0 replies; 13+ messages in thread
From: Miles Bader @ 2008-05-09  0:43 UTC (permalink / raw)
  To: James Cloos; +Cc: Chong Yidong, emacs-devel, Jason Rumney

James Cloos <cloos@jhcloos.com> writes:
> Jason> Is there any program that can dump a PNG header in some readable
> Jason> format, so we can compare yours with the image that Gimp saves?
>
> Yes.  ESR's Sng converts between binary png files and a sexp notation.

Not necessary anymore, I think -- it seems that the "gimped" versions
worked because the gimp chopped them down to 8 bits per channel...

-Miles

-- 
My books focus on timeless truths.  -- Donald Knuth




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08 15:39         ` Miles Bader
  2008-05-08 15:51           ` Jason Rumney
  2008-05-08 18:19           ` Chong Yidong
@ 2008-05-09  1:00           ` Chong Yidong
  2008-05-09  1:10             ` Miles Bader
  2008-05-09  2:35           ` Chong Yidong
  3 siblings, 1 reply; 13+ messages in thread
From: Chong Yidong @ 2008-05-09  1:00 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel, Jason Rumney

Miles Bader <miles@gnu.org> writes:

> Upon looking closer, I see on very odd attribute:  while the original
> image I wrote was RGBA, 8-bits per channel, the decimated versions
> written by imagemagick are RGBA, 16-bits per channel...  The Emacs
> PNG-reading code asks libpng to convert 16-bit-per-channel images to
> 8-bits per channel, but as such images are fairly rare, it may be that
> libpng doesn't do it correctly.
>
> If I open the original RGBA 8-bits per channel image with Emacs, indeed,
> it handles the alpha-channel correctly.

It looks like Emacs doesn't handle 16-bit RGBA png images correctly,
according to the images on this page:

http://www.fnordware.com/superpng/pnggrad16rgba.png
http://www.fnordware.com/superpng/pngtest16rgba.png

The 8-bit RGBA test image on the same page works fine:

http://www.fnordware.com/superpng/pngtest8rgba.png

The weird thing, though, is that the image emacs5-256.png which you
sent, whose alpha channel is also much up, is 8-bit!  This can be
verified by stepping through image.c in gdb, or using pngtools.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-09  1:00           ` Chong Yidong
@ 2008-05-09  1:10             ` Miles Bader
  0 siblings, 0 replies; 13+ messages in thread
From: Miles Bader @ 2008-05-09  1:10 UTC (permalink / raw)
  To: Chong Yidong; +Cc: emacs-devel, Jason Rumney

On Fri, May 9, 2008 at 10:00 AM, Chong Yidong <cyd@stupidchicken.com> wrote:
>  The weird thing, though, is that the image emacs5-256.png which you
>  sent, whose alpha channel is also much up, is 8-bit!  This can be
>  verified by stepping through image.c in gdb, or using pngtools.

Actually, "emacs5-256.png" was 16-bit ... last night!  However I
replaced it with an 8-bit version after I found the problem was with
16-bit images.

I've tested emacs with the new 8-bit version, and it works correctly.

[If you really want I still have the old 16-bit versions, but it looks
like the issue also happens with the "fnordware.com" images, so I
assume no need...]

-Miles

-- 
Do not taunt Happy Fun Ball.




^ permalink raw reply	[flat|nested] 13+ messages in thread

* Re: PNG image files with alpha channel
  2008-05-08 15:39         ` Miles Bader
                             ` (2 preceding siblings ...)
  2008-05-09  1:00           ` Chong Yidong
@ 2008-05-09  2:35           ` Chong Yidong
  3 siblings, 0 replies; 13+ messages in thread
From: Chong Yidong @ 2008-05-09  2:35 UTC (permalink / raw)
  To: Miles Bader; +Cc: emacs-devel, Jason Rumney

Miles Bader <miles@gnu.org> writes:

> So the problem may in fact be something with the libpng 16-to-8-bit
> conversion code...

I found the error.  When setting the background color, we must provide
it in the original bit-depth of the image, even if we call
png_set_strip_16.  So, for 16-bit png images, it's just a matter of
supplying the background color at a 16-bit depth.

I've checked in a fix.




^ permalink raw reply	[flat|nested] 13+ messages in thread

end of thread, other threads:[~2008-05-09  2:35 UTC | newest]

Thread overview: 13+ messages (download: mbox.gz follow: Atom feed
-- links below jump to the message on this page --
2008-05-08  4:46 PNG image files with alpha channel Miles Bader
2008-05-08 11:48 ` Chong Yidong
2008-05-08 12:05   ` Jason Rumney
2008-05-08 15:02     ` Miles Bader
2008-05-08 15:18       ` Jason Rumney
2008-05-08 15:39         ` Miles Bader
2008-05-08 15:51           ` Jason Rumney
2008-05-08 18:19           ` Chong Yidong
2008-05-09  1:00           ` Chong Yidong
2008-05-09  1:10             ` Miles Bader
2008-05-09  2:35           ` Chong Yidong
2008-05-08 23:47         ` James Cloos
2008-05-09  0:43           ` Miles Bader

Code repositories for project(s) associated with this external index

	https://git.savannah.gnu.org/cgit/emacs.git
	https://git.savannah.gnu.org/cgit/emacs/org-mode.git

This is an external index of several public inboxes,
see mirroring instructions on how to clone and mirror
all data and code used by this external index.