[reportlab-users] Transparent png

762 views
Skip to first unread message

Arkadi Colson

unread,
May 23, 2017, 5:55:20 AM5/23/17
to reportl...@lists2.reportlab.com
Hi

Does anybody know if it's possible to use tranparent png images with the
code below:

self.data[x][y] = Paragraph(
'<img src="' + filename + '"
valign="middle"/>', style=self.style_def)

Thx!

_______________________________________________
reportlab-users mailing list
reportl...@lists2.reportlab.com
https://pairlist2.pair.net/mailman/listinfo/reportlab-users

Tim Roberts

unread,
May 23, 2017, 12:37:28 PM5/23/17
to reportlab-users
Arkadi Colson wrote:
> Does anybody know if it's possible to use tranparent png images with the
> code below:
>
> self.data[x][y] = Paragraph(
> '<img src="' + filename + '"
> valign="middle"/>', style=self.style_def)

Wouldn't it have been quicker just to try it?

Although I don't know the answer, I will point out that transparency has
always been a tricky issue with PostScript and, by extension, PDF. Both
standards were designed with paper and printing in mind, where
transparency does not exist. Most professional print shops will not
accept PDF files with embedded transparency, because it's not clear what
that means.

--
Tim Roberts, ti...@probo.com
Providenza & Boekelheide, Inc.

Glenn Linderman

unread,
May 23, 2017, 2:29:34 PM5/23/17
to reportl...@lists2.reportlab.com
On 5/23/2017 9:37 AM, Tim Roberts wrote:
Arkadi Colson wrote:
Does anybody know if it's possible to use tranparent png images with the 
code below:

self.data[x][y] = Paragraph(
                             '<img src="' + filename + '" 
valign="middle"/>', style=self.style_def)
Wouldn't it have been quicker just to try it?

Although I don't know the answer, I will point out that transparency has
always been a tricky issue with PostScript and, by extension, PDF.  Both
standards were designed with paper and printing in mind, where
transparency does not exist.  Most professional print shops will not
accept PDF files with embedded transparency, because it's not clear what
that means.

I know that transparency isn't supported in some graphics formats, and that there have been issues with that in various programs/browsers/etc. that didn't understand the concept, because they were designed prior to the existence of the concept.

However, the concept seems extremely straightforward for printing: transparent means "don't print there".  This seems to be exactly the same concept as stripping images for the 4-color printing process: color images are reduced to "print density of each of CYMK" for each color for each pixel, and the 0 density is (effectively) transparent.

Could you elaborate on the issues that professional print shops have with transparency? It doesn't seem to be that they can't produce a density of 0 for swath of certain (even all) colors in areas of the printed page: except for prints consisting totally of color pictures, nearly all pages in all publications have areas where no ink of any color is laid on the paper.  Is it because the concept of transparency in image files (particularly, those embedded in Postscript or PDF) hasn't been sufficiently standardized? Or what?

Tim Roberts

unread,
May 23, 2017, 3:46:36 PM5/23/17
to reportlab-users
Glenn Linderman wrote:
>
> However, the concept seems extremely straightforward for printing:
> transparent means "don't print there". This seems to be exactly the
> same concept as stripping images for the 4-color printing process:
> color images are reduced to "print density of each of CYMK" for each
> color for each pixel, and the 0 density is (effectively) transparent.

Does it? Does it mean "deposit no ink", or does it mean "deposit white
ink"?

The problem is not dissimilar to doing projection rendering in a 3D
graphics application. To determine the color of a pixel, if there is no
transparency or alpha, all I have to look at is the top-most object at
this location. If there is transparency or alpha, I have to look at all
of the objects to blend them.


> Could you elaborate on the issues that professional print shops have
> with transparency? It doesn't seem to be that they can't produce a
> density of 0 for swath of certain (even all) colors in areas of the
> printed page: except for prints consisting totally of color pictures,
> nearly all pages in all publications have areas where no ink of any
> color is laid on the paper. Is it because the concept of transparency
> in image files (particularly, those embedded in Postscript or PDF)
> hasn't been sufficiently standardized? Or what?

You're assuming all commercial printers use a 4-color process. 4-color
is only used in lower-end print jobs, and when you move to spot colors
it gets way more complicated. Transparency confuses overprinting and
knockouts. If they have a sophisticated rasterizer, it should be able
to come up with something close, but in high-end printing, close is not
good enough. The production printing company I work with will not
accept PDF files that include images with transparency. Their preflight
software simply rejects it.

Also, transparency means more than just "no ink here". You move into
generalized alpha blending, and blending print inks produces way
different results than blending pixels.

Arkadi Colson

unread,
May 24, 2017, 3:17:38 AM5/24/17
to reportlab-users, Tim Roberts

I tried it and the result is this:

The black square should be a transparent image and looks like this:

Both are png images.
The first one which is appearing correctly is "PNG image data, 48 x 48, 8-bit/color RGBA, non-interlaced". The black square is "PNG image data, 48 x 48, 8-bit gray+alpha, non-interlaced".

Any idea why the "gray+alpha" isn't showing up correctly?

Thx!

Robin Becker

unread,
May 24, 2017, 4:01:35 AM5/24/17
to reportlab-users

On 24/05/2017 08:17, Arkadi Colson wrote:
> I tried it and the result is this:
>
> The black square should be a transparent image and looks like this:
>
> Both are png images.
> The first one which is appearing correctly is "PNG image data, 48 x 48,
> 8-bit/color RGBA, non-interlaced". The black square is "PNG image data, 48 x 48,
> 8-bit gray+alpha, non-interlaced".
>
> Any idea why the "gray+alpha" isn't showing up correctly?
>
> Thx!
>

Hi Arkadi,

I'm almost sure that we don't support lots of stuff regarding colour mappings
especially with images.

Since PNG is not native for PDF I think we're just doing this for PNG

> if mode=='RGBA':
> if Image.VERSION.startswith('1.1.7'): im.load()
> self._dataA = ImageReader(im.split()[3])
> im = im.convert('RGB')
> self.mode = 'RGB'
> elif mode not in ('L','RGB','CMYK'):
> if im.format=='PNG' and im.mode=='P' and 'transparency' in im.info:
> im = im.convert('RGBA')
> self._dataA = ImageReader(im.split()[3])
> im = im.convert('RGB')
> else:
> im = im.convert('RGB')
> self.mode = 'RGB'


I guess we could do something similar for PNG with gray, presumably we would get
a two plane image (with gray as one plane) the alpha would map to _deltaA as
before. Then later we would need to handle two plane images as well as the
standard three plane ones. What mode do your images have when opened in PIL/Pillow?

>
> On 23-05-17 18:37, Tim Roberts wrote:
>> Arkadi Colson wrote:
>>> Does anybody know if it's possible to use tranparent png images with the
>>> code below:
>>>
>>> self.data[x][y] = Paragraph(
>>> '<img src="' + filename + '"
>>> valign="middle"/>', style=self.style_def)
>> Wouldn't it have been quicker just to try it?
>>
>> Although I don't know the answer, I will point out that transparency has
>> always been a tricky issue with PostScript and, by extension, PDF. Both
>> standards were designed with paper and printing in mind, where
>> transparency does not exist. Most professional print shops will not
>> accept PDF files with embedded transparency, because it's not clear what
>> that means.
>>
--
Robin Becker

Arkadi Colson

unread,
May 24, 2017, 4:22:39 AM5/24/17
to Robin Becker, reportlab-users
Hi

I'm not really sure how to get the mode. I attached the image. Perhaps
you can give it a try?
Thanks a lot!

Arkadi
image.png

Robin Becker

unread,
May 24, 2017, 5:19:39 AM5/24/17
to reportlab-users
OK it turns out to be LA which is kind of what I suspected.




On 24/05/2017 09:22, Arkadi Colson wrote:
> Hi
>
> I'm not really sure how to get the mode. I attached the image. Perhaps you can
> give it a try?
> Thanks a lot!
>
in python

C:\code\hg-repos\reportlab\tmp>python
Python 2.7.13 (v2.7.13:a06454b1afa1, Dec 17 2016, 20:53:40) [MSC v.1500 64 bit
(AMD64)] on win32
Type "help", "copyright", "credits" or "license" for more information.
>>> from PIL import Image
>>> im=Image.open('gray-alpha.png')
>>> im.mode
'LA'
>>>



> Arkadi
>
>
> On 24-05-17 10:01, Robin Becker wrote:
>>
>> On 24/05/2017 08:17, Arkadi Colson wrote:
>>> I tried it and the result is this:
>>>
>>> The black square should be a transparent image and looks like this:
>>>
>>> Both are png images.
>>> The first one which is appearing correctly is "PNG image data, 48 x 48,
>>> 8-bit/color RGBA, non-interlaced". The black square is "PNG image data, 48 x 48,
>>> 8-bit gray+alpha, non-interlaced".
>>>
>>> Any idea why the "gray+alpha" isn't showing up correctly?
>>>
>>> Thx!
>>>
>>
>> Hi Arkadi,
>>
>> I'm almost sure that we don't support lots of stuff regarding colour mappings
>> especially with images.
>>
>> Since PNG is not native for PDF I think we're just doing this for PNG
.........

Arkadi Colson

unread,
May 24, 2017, 5:36:29 AM5/24/17
to Robin Becker, reportlab-users
Ah ok. It's that simple :-). Are you going to implement it in one of the
next versions or what's the next step?

Thanks already for your effort!

Robin Becker

unread,
May 24, 2017, 5:54:14 AM5/24/17
to reportlab-users
On 24/05/2017 10:36, Arkadi Colson wrote:
> Ah ok. It's that simple :-). Are you going to implement it in one of the next
> versions or what's the next step?
>
> Thanks already for your effort!
>
I have tested a small change to the ImageReader class which seems to do the
trick for PDF at least. Our graphics stuff is way behind anyhow so it won't work
there. It will appear at bitbucket shortly. Or wait for version 3.4.12 to appear
at our non-release pypi https://www.reportlab.com/pypi).


In the meantime if you know how to patch the source you could try this

diff -r 823a45c95ed8 src/reportlab/lib/utils.py
--- a/src/reportlab/lib/utils.py Tue May 23 15:30:14 2017 +0100
+++ b/src/reportlab/lib/utils.py Wed May 24 10:51:47 2017 +0100
@@ -882,11 +882,12 @@
else:
im = self._image
mode = self.mode = im.mode
- if mode=='RGBA':
+ if mode in ('LA','RGBA'):
if Image.VERSION.startswith('1.1.7'): im.load()
- self._dataA = ImageReader(im.split()[3])
- im = im.convert('RGB')
- self.mode = 'RGB'
+ self._dataA = ImageReader(im.split()[3 if mode=='RGBA'
else 1])
+ nm = mode[:-1]
+ im = im.convert(nm)
+ self.mode = nm
elif mode not in ('L','RGB','CMYK'):
if im.format=='PNG' and im.mode=='P' and
'transparency' in im.info:
im = im.convert('RGBA')

--
Robin Becker

Robin Becker

unread,
May 24, 2017, 6:12:13 AM5/24/17
to reportlab-users
As an implementational detail (if that's a word) what we convert non-jpeg images
into rgb or L. If there's an alpha channel it's converted to an image mask for
those images. It was simple to allow for LA as well as as RGBA. For native (ie
jpeg) images transparency is handled by making a specific color range into a
mask. That also works for bitmap without the A channel.

Whether transparency has any real utility in printing is entirely another
matter. It's certainly not clear whether printing inks on top of each other is
the same as the additive process I see on my screen.
--
Robin Becker

Arkadi Colson

unread,
May 24, 2017, 7:12:17 AM5/24/17
to Robin Becker, reportlab-users
Thanks a lot for the help. It's working great!

Robin Becker

unread,
May 24, 2017, 7:16:50 AM5/24/17
to ark...@smartbit.be, reportlab-users
I have pushed to bitbucket (crediting your inspiration) and made a non-release
package here https://www.reportlab.com/pypi


On 24/05/2017 12:12, Arkadi Colson wrote:
> Thanks a lot for the help. It's working great!
>
>
> On 24-05-17 11:54, Robin Becker wrote:
>> On 24/05/2017 10:36, Arkadi Colson wrote:
>>> Ah ok. It's that simple :-). Are you going to implement it in one of the next
>>> versions or what's the next step?
>>>
>>> Thanks already for your effort!
>........
--
Robin Becker
Reply all
Reply to author
Forward
0 new messages