New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Overlay RGBA? Transparency not supported? #199

Closed
jtkeyva opened this Issue Feb 23, 2015 · 30 comments

Comments

Projects
None yet
@jtkeyva

jtkeyva commented Feb 23, 2015

The overlay feature is nice, but couldn't figure out how to use png files with portions that are transparent. Is it possible to have a png as an overlay but with areas that are cut out?
Thanks

@waveform80

This comment has been minimized.

Owner

waveform80 commented Mar 13, 2015

At the moment, the overlay subsystem in picamera only uses RGB data with the renderer. In other words, alpha data is thrown away before passing the RGB buffer to the renderer. I've no idea if the renderer will accept an RGBA buffer; there is a format which suggests support for this but I don't know whether the firmware will take any notice of the alpha channel.

If anyone wants to play with this and find out, please do and report back! I think it's relatively easy - just play with the overlay class' MMAL format in picamera/renderers.py and feed the renderer something with 4 bytes per pixel instead of three.

@waveform80

This comment has been minimized.

Owner

waveform80 commented Mar 22, 2015

Okay, I've had a chance to play with this today. Quite simply it looks like the renderer system ignores the alpha channel of any provided buffer. The patch I used was as follows:

diff --git a/picamera/renderers.py b/picamera/renderers.py
index ab72bb8..51be8e5 100644
--- a/picamera/renderers.py
+++ b/picamera/renderers.py
@@ -527,8 +527,8 @@ class PiOverlayRenderer(PiRenderer):
         fmt = port[0].format
         mmal.mmal_format_copy(
             fmt, parent._camera[0].output[parent.CAMERA_PREVIEW_PORT][0].format)
-        fmt[0].encoding = mmal.MMAL_ENCODING_RGB24
-        fmt[0].encoding_variant = mmal.MMAL_ENCODING_RGB24
+        fmt[0].encoding = mmal.MMAL_ENCODING_RGBA
+        fmt[0].encoding_variant = mmal.MMAL_ENCODING_RGBA
         if size is not None:
             w, h = size
             fmt[0].es[0].video.width = mmal.VCOS_ALIGN_UP(w, 32)
@@ -573,7 +573,7 @@ class PiOverlayRenderer(PiRenderer):
         """
         port = self.renderer[0].input[0]
         fmt = port[0].format
-        bp = ct.c_uint8 * (fmt[0].es[0].video.width * fmt[0].es[0].video.height * 3)
+        bp = ct.c_uint8 * (fmt[0].es[0].video.width * fmt[0].es[0].video.height * 4)
         try:
             sp = bp.from_buffer(source)
         except TypeError:

And the test script was:

import picamera
from PIL import Image
from time import sleep

img = Image.open('test.png')

with picamera.PiCamera() as camera:
    camera.start_preview(alpha=192)
    camera.add_overlay(img.tostring(), size=(1280, 720))
    sleep(5)

Where test.png was a 1280x720 PNG with several regions incorporating partial and full alpha transparency.

To be honest, this was pretty much what I was expecting (why provide an alpha value for the entire renderer if it supports per-pixel alpha), so I'm afraid this functionality isn't going to be supported unless you can persuade upstream to implement it. I'll leave this open and mark it as an upstream enhancement for now, but I wouldn't hold your breath (my hunch is this will be in the "too difficult" category).

@jgreth

This comment has been minimized.

jgreth commented Sep 6, 2015

I can follow your patch logic, but when i make your changes to my /usr/share/pyshared/picamera/renderers.py and start your script with an image (png) i created in PS CS6 (616x600px, colored layer, erased some areas, save as png, no background) it gets repeated and horrible "fuzzed"...

What could be wrong? Did you something special? What is you test.png looking like?

my test.py:

#!/usr/bin/python
import picamera
from PIL import Image
from time import sleep

img = Image.open('test.png')

with picamera.PiCamera() as camera:
  camera.resolution = (616,600)
  camera.start_preview(alpha=192)
  camera.add_overlay(img.tostring(), size=(616, 600))
  while True:
    sleep(1)

Here my files:
test.png

my result

@waveform80

This comment has been minimized.

Owner

waveform80 commented Sep 6, 2015

Have a read of the overlay recipe - the source data needs to have a width which is a multiple of 32, and a height which is a multiple of 16 (1280x720 is which is why my test worked).

@jgreth

This comment has been minimized.

jgreth commented Sep 7, 2015

Ah... ok, that was a hint into the right direction. 👍 Thank's!
Now I resized the png to 1280x720 and ran

#!/usr/bin/python
import picamera
from PIL import Image
from time import sleep
img = Image.open('test.png')
with picamera.PiCamera() as camera:
  camera.start_preview(alpha=192)
  camera.add_overlay(img.tostring(), size=(1280, 720))
  while True:
    sleep(1)

i get a overlay, but this is not my "bubble" - its just the blue background and a white square. Looks like this:
2015-09-07 11 34 12

But when use the example (modified a cause of this) and execute

#!/usr/bin/python
import picamera
from PIL import Image
from time import sleep
with picamera.PiCamera() as camera:
    width = 1280
    height = 720
    sizeA=(width,height)
    camera.resolution = (width,height)
    camera.framerate = 24
    camera.start_preview()
    img = Image.open("test.png")
    #img.convert("RGBA")
    #img.resize((width, height), Image.ANTIALIAS)
    pad = Image.new("RGBA", (
        ((img.size[0] + 31) // 32) * 32,
        ((img.size[1] + 15) // 16) * 16,
        ))
    pad.paste(img, (0, 0), img)
    #mix = Image.alpha_composite(pad,img)
    o = camera.add_overlay(pad.tostring(), size=sizeA)
    o.alpha = 128
    o.layer = 3
    while True:
        sleep(1)

i get the following better resut:
2015-09-07 11 39 34
But thats not completely stisfying, cause when i now change o.alpha = 128 to o.alpha = 255 (for having a full color overlay) the center "bubble" gets black - not transparent.
Do you have any ideas here?

@waveform80

This comment has been minimized.

Owner

waveform80 commented Sep 7, 2015

My guess is the only difference is the fact you're setting camera resolution in the second recipe (the padding stuff is unnecessary as the test PNG is already has a resolution which is a multiple of 32 x 16 blocks). Still, it just goes to demonstrate what I mentioned above: the firmware ignores the alpha channel of image data in renderers.

@6by9

This comment has been minimized.

6by9 commented Sep 8, 2015

I suspect it is that the firmware will ignore the alpha channel if it is given a global alpha.
You're setting MMAL_PARAMETER_DISPLAYREGION with MMAL_DISPLAY_SET_ALPHA to provide a global alpha, so I believe that is overriding the alpha channel.
...
Then again the dispmanx call that results from video_render is always passing in a DISPMANX_ALPHA_T (interface/vmcs_host/vc_dispmanx_types.h) with flags = DISPMANX_FLAGS_ALPHA_FIXED_ALL_PIXELS. Adding in per pixel alpha raises the question of exposing premultiplied or not, and the MIX flag.

If you want firmware changes investigated further, please raise an issue on raspberrypi/firmware with a link to here, and I'll see if I can find some time to look into it.

@waveform80

This comment has been minimized.

Owner

waveform80 commented Sep 8, 2015

Ah, intriguing - I'll try and find some time to try out the renderer component without setting any alpha at all (you're absolutely correct that it's always calling MMAL_DISPLAY_SET_ALPHA even when it's not strictly necessary, so it's worth experimenting without that).

@6by9

This comment has been minimized.

6by9 commented Sep 8, 2015

As per my followup comment, that actually won't make a difference, so save your effort.
Alpha defaults to 255, and the dispmanx call always sets DISPMANX_FLAGS_ALPHA_FIXED_ALL_PIXELS, so nothing you can do can change that. :-(
I never realised that video_render never got used with image formats having an alpha channel even though it supported them - you live and learn.

If the OP is that fussed then raise an issue and I'll see if it is possible to solve it without opening a big can of worms. The other approach is to use dispmanx directly, but that involves a moderate amount more fiddling around to get it to work.

@eldog

This comment has been minimized.

eldog commented Apr 8, 2016

If anyone is attempting this, you can hack an image overlay with alpha using pngview. Make sure you set the layer to 3 or higher so you overlay the camera preview. Use subprocess to call the executable from python.

@mchobby

This comment has been minimized.

mchobby commented Nov 1, 2016

The tuning of the /picamera/renderers.py was exactly what I was expecting for.
Unfortunately, the source code did changed a lot.
Someone does he has an idea about How to patch the new code?

@waveform80

This comment has been minimized.

Owner

waveform80 commented Nov 4, 2016

@mchobby feel free to make a fork of picamera and commit your changes to that fork. Even if the changes are too big / complex to merge directly I'd be happy to take a look when I get a mo (apologies I don't have much time for picamera at the moment - I'll try and catch up in a month or so).

@preethaw

This comment has been minimized.

preethaw commented Dec 6, 2016

Hi, That's the exact kind of code that I wanted too. But I could not make the changes in the picamera/renderers.py. So transparency is achieved but the opaque part of the image is not visible properly.
I could not understand in which method and how to make the changes.
Would be great if somebody could help with the renderers.py file.
20161206_144730

@waveform80

This comment has been minimized.

Owner

waveform80 commented Dec 6, 2016

Actually the work on #196 should permit "proper" RGBA transparency support too (I recently managed to get a transparent PNG overlaid on both preview and recording with the branch mentioned in that ticket). However, full RGBA transparency does heavily limit the available resolution / framerate due to the amount of bandwidth required for chucking full RGBA buffers around. Anyway, that's probably not much use to most people yet (the mmalobj API is below the level most people use picamera), but I'm working on something a bit more high level too. Whether that makes it into a release before xmas is very debatable though.

@sczhengyabin

This comment has been minimized.

sczhengyabin commented Dec 30, 2016

Same problem here. waiting for updating...

@AdrianAntunez

This comment has been minimized.

AdrianAntunez commented Jan 30, 2017

I'm also waiting for that update. It partially works but when I set the alpha channel to 255 the transparent regions become black. I know it can be achieved using mmal and DispmanX as it is shown here but a feature like that using picamera would be perfect!

If I can help with something, just let me know.

@waveform80

This comment has been minimized.

Owner

waveform80 commented Jan 30, 2017

raspidmx doesn't use MMAL at all; it's all dispmanx. Integrating that into picamera would be more work than I can afford to do at the moment (there'll be some dispmanx stuff in 1.13 for screen capture, but nothing for rendering).

Currently I'm tidying up #196 for release; it'll have the mmalobj layer for doing overlays (or more precisely generic transforms) but there won't be a high level API yet (can't afford the time to spend on that at the moment).

@AdrianAntunez

This comment has been minimized.

AdrianAntunez commented Jan 31, 2017

Thanks for answering waveform80,

So I will wait for that release that includes the #196 enhancements, afterwards I will try to figure out what can I do to solve my issue, which is having an overlay with a RGBA PNG with both preview and overlay in full color (255 alpha), even if it means diving into lower levels.

@gauthierlerouzic

This comment has been minimized.

gauthierlerouzic commented Jan 31, 2017

Hi,
In waiting to a real overlay RGBA with python I used the raspidmx, and raspivid
you can see a method in this page

@AdrianAntunez

This comment has been minimized.

AdrianAntunez commented Jan 31, 2017

Hi @gauthierlerouzic,

Yep, that's the workaround I will be using meanwhile, but I just don't like to use an external process when it could be done in the python one.

@pirquessa

This comment has been minimized.

pirquessa commented Jan 31, 2017

Please share your results. It would be good to see how you do that :)

@gauthierlerouzic

This comment has been minimized.

gauthierlerouzic commented Jan 31, 2017

Hi @AdrianAntunez ,

I understand and i'm agree with you.
when will be possible to do that only with python, i will change my code.
But for the moment I need a working solution. :)
img_0987
For me, I install pngview. and run this command :
./pngview -b 0 -l 3 Carte.png & raspivid -t 0 -vf

I have just a problem for break run.
When I do Ctrl + C, raspivid break, but pngview doesn't want to break.
If anyone have a idea. :)

@6by9

This comment has been minimized.

6by9 commented Feb 24, 2017

FYI I have a fix for this. video_render if given RGBA data will take the per pixel alpha and ignore the global alpha.
I'd guess the updated firmware should be on the rpi-update branch around the middle to end of next week.

@waveform80

This comment has been minimized.

Owner

waveform80 commented Feb 24, 2017

I think I can sneak this into 1.13 ;)

@waveform80 waveform80 self-assigned this Feb 24, 2017

@waveform80 waveform80 added this to the 1.13 milestone Feb 24, 2017

waveform80 added a commit that referenced this issue Feb 25, 2017

Re #199
Apparently old firmwares don't support BGRA on renderers (so don't test
it; RGBA is enough to confirm the size calculations). Also, bizarrely,
in Python 2 a memoryview (which is explicitly built on buffer-protocol
objects) is not itself a buffer-protocol object (it is in 3) so just
have buffer_bytes calculate the size in bytes.

popcornmix added a commit to raspberrypi/firmware that referenced this issue Mar 1, 2017

kernel: BCM2835-V4L2: Ensure H264 header bytes get a sensible timestamp
kernel:  BCM2835-V4L2: Correctly denote key frames in encoded data
kernel:  bcm2835-gpio-exp: Driver for GPIO expander via mailbox service
See: raspberrypi/linux#1852

kernel: Add overlay for ads1115 ADCs
See: raspberrypi/linux#1864

kernel: Add support for Fe-Pi audio sound card
See: raspberrypi/linux#1867

kernel: amba_pl011: Round input clock up
kernel: clk-bcm2835: Correct the prediv logic

firmware: Redo CEC code cleanup 3: Removed CEC topology computation
firmware: Redo CEC code cleanup 4: Removed unused functions
firmware: Redo CEC code cleanup 5: Removed Rx processing
firmware: Redo CEC code cleanup 6: Logging changed to VCOS
firmware: Redo CEC code cleanup 7: Removed hdmi_state_machine_clock_changed
firmware: Redo CEC code cleanup 8: fixed hdmi state machine clk
firmware: Redo CEC code cleanup 10: misc cosmetic changes
firmware: Fixup CEC code cleanup 8: fixed hdmi state machine clk
firmware: hdmi: Add way of forcing logging for hdmi and cec from boot
firmware: Redo CEC code cleanup 11: cec_release_logical_addr

firmware: arm_loader: Respect smsc95xx.macaddr parameter
See: raspberrypi/linux#1865

firmware: vec: Fix progressive scan composite mode
See: #683

firmware: vec: PAL_M mode is 525/60
See: #756

firmware: IL ISP: Support Bayer
firmware: IL ISP: Fix error in stride calcs for YUYV formats
firmware: video_render: buffer size fixup for ARGB888

firmware: video_render: Support per-pixel alpha on RGBA input
See: waveform80/picamera#199

popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Mar 1, 2017

kernel: BCM2835-V4L2: Ensure H264 header bytes get a sensible timestamp
kernel:  BCM2835-V4L2: Correctly denote key frames in encoded data
kernel:  bcm2835-gpio-exp: Driver for GPIO expander via mailbox service
See: raspberrypi/linux#1852

kernel: Add overlay for ads1115 ADCs
See: raspberrypi/linux#1864

kernel: Add support for Fe-Pi audio sound card
See: raspberrypi/linux#1867

kernel: amba_pl011: Round input clock up
kernel: clk-bcm2835: Correct the prediv logic

firmware: Redo CEC code cleanup 3: Removed CEC topology computation
firmware: Redo CEC code cleanup 4: Removed unused functions
firmware: Redo CEC code cleanup 5: Removed Rx processing
firmware: Redo CEC code cleanup 6: Logging changed to VCOS
firmware: Redo CEC code cleanup 7: Removed hdmi_state_machine_clock_changed
firmware: Redo CEC code cleanup 8: fixed hdmi state machine clk
firmware: Redo CEC code cleanup 10: misc cosmetic changes
firmware: Fixup CEC code cleanup 8: fixed hdmi state machine clk
firmware: hdmi: Add way of forcing logging for hdmi and cec from boot
firmware: Redo CEC code cleanup 11: cec_release_logical_addr

firmware: arm_loader: Respect smsc95xx.macaddr parameter
See: raspberrypi/linux#1865

firmware: vec: Fix progressive scan composite mode
See: raspberrypi/firmware#683

firmware: vec: PAL_M mode is 525/60
See: raspberrypi/firmware#756

firmware: IL ISP: Support Bayer
firmware: IL ISP: Fix error in stride calcs for YUYV formats
firmware: video_render: buffer size fixup for ARGB888

firmware: video_render: Support per-pixel alpha on RGBA input
See: waveform80/picamera#199

popcornmix added a commit to raspberrypi/firmware that referenced this issue Mar 1, 2017

kernel: BCM2835-V4L2: Ensure H264 header bytes get a sensible timestamp
kernel:  BCM2835-V4L2: Correctly denote key frames in encoded data
kernel:  bcm2835-gpio-exp: Driver for GPIO expander via mailbox service
See: raspberrypi/linux#1852

kernel: Add overlay for ads1115 ADCs
See: raspberrypi/linux#1864

kernel: Add support for Fe-Pi audio sound card
See: raspberrypi/linux#1867

kernel: amba_pl011: Round input clock up
kernel: clk-bcm2835: Correct the prediv logic

firmware: Redo CEC code cleanup 3: Removed CEC topology computation
firmware: Redo CEC code cleanup 4: Removed unused functions
firmware: Redo CEC code cleanup 5: Removed Rx processing
firmware: Redo CEC code cleanup 6: Logging changed to VCOS
firmware: Redo CEC code cleanup 7: Removed hdmi_state_machine_clock_changed
firmware: Redo CEC code cleanup 8: fixed hdmi state machine clk
firmware: Redo CEC code cleanup 10: misc cosmetic changes
firmware: Fixup CEC code cleanup 8: fixed hdmi state machine clk
firmware: hdmi: Add way of forcing logging for hdmi and cec from boot
firmware: Redo CEC code cleanup 11: cec_release_logical_addr

firmware: arm_loader: Respect smsc95xx.macaddr parameter
See: raspberrypi/linux#1865

firmware: vec: Fix progressive scan composite mode
See: #683

firmware: vec: PAL_M mode is 525/60
See: #756

firmware: IL ISP: Support Bayer
firmware: IL ISP: Fix error in stride calcs for YUYV formats
firmware: video_render: buffer size fixup for ARGB888

firmware: video_render: Support per-pixel alpha on RGBA input
See: waveform80/picamera#199

popcornmix added a commit to Hexxeh/rpi-firmware that referenced this issue Mar 1, 2017

kernel: BCM2835-V4L2: Ensure H264 header bytes get a sensible timestamp
kernel:  BCM2835-V4L2: Correctly denote key frames in encoded data
kernel:  bcm2835-gpio-exp: Driver for GPIO expander via mailbox service
See: raspberrypi/linux#1852

kernel: Add overlay for ads1115 ADCs
See: raspberrypi/linux#1864

kernel: Add support for Fe-Pi audio sound card
See: raspberrypi/linux#1867

kernel: amba_pl011: Round input clock up
kernel: clk-bcm2835: Correct the prediv logic

firmware: Redo CEC code cleanup 3: Removed CEC topology computation
firmware: Redo CEC code cleanup 4: Removed unused functions
firmware: Redo CEC code cleanup 5: Removed Rx processing
firmware: Redo CEC code cleanup 6: Logging changed to VCOS
firmware: Redo CEC code cleanup 7: Removed hdmi_state_machine_clock_changed
firmware: Redo CEC code cleanup 8: fixed hdmi state machine clk
firmware: Redo CEC code cleanup 10: misc cosmetic changes
firmware: Fixup CEC code cleanup 8: fixed hdmi state machine clk
firmware: hdmi: Add way of forcing logging for hdmi and cec from boot
firmware: Redo CEC code cleanup 11: cec_release_logical_addr

firmware: arm_loader: Respect smsc95xx.macaddr parameter
See: raspberrypi/linux#1865

firmware: vec: Fix progressive scan composite mode
See: raspberrypi/firmware#683

firmware: vec: PAL_M mode is 525/60
See: raspberrypi/firmware#756

firmware: IL ISP: Support Bayer
firmware: IL ISP: Fix error in stride calcs for YUYV formats
firmware: video_render: buffer size fixup for ARGB888

firmware: video_render: Support per-pixel alpha on RGBA input
See: waveform80/picamera#199
@preethaw

This comment has been minimized.

preethaw commented Mar 9, 2017

Thanks a lot for the #199 fix. Image overlay is working good.

I have an image that is partially transparent, and what I noticed in the output is that all transparent part is behaving like black. Just to ascertain the fact I overlayed it with the image below with 4 different colors and rest of the area transparent. I am attaching my input and output images.

What should I do to make black look black and transparent look transparent ?

Thanks in advance

Preetha
picam

@6by9

This comment has been minimized.

6by9 commented Mar 9, 2017

Just to confirm, your TIF image is 32bpp RGBA with alpha=50% (or some constant) across the whole image?
If so I would have expected to see a black square. If you'll confirm your RGBA values for each area I'll try to find time to recreate.

Composition is not my area of expertise, I just found a suitable set of defines to hang things on. I started reading up about premultiplied alpha and the like, and decided it wasn't worth the effort.

@preethaw

This comment has been minimized.

preethaw commented Mar 10, 2017

Yes the TIF image is at 32bpp since the image size is 3.51MB and the dimensions are 1280X720.
The alpha value is set at 128 which would correspond to 50%.
I have used TIF and PNG formats so as to not loose the alpha values.
I am attaching a PNG format of the image (as TIF is not supported). PNG produces similar output as the TIF image.

Thanks once again.
Preetha

box

mkreisl added a commit to xbianonpi/xbian-package-firmware that referenced this issue Mar 26, 2017

verup and fixes, build to stable/main:
- firmware: dtoverlay: find symbols, write properties
  See: #613

- firmware: arm_loader: Clean up cmdline, add local-mac-address to DT
  See: #613

- firmware: gpuserv: Boost gpu frequencies when in use

- firmware: ILCamera: Add option to disable ISP processing stages

- firmware: MMAL/IL: Allow video render to take non aligned sliceheight
- firmware: IL ISP: Support unaligned nSliceHeight on input
- firmware: Redo CEC code cleanup 3: Removed CEC topology computation
- firmware: Redo CEC code cleanup 4: Removed unused functions
- firmware: Redo CEC code cleanup 5: Removed Rx processing
- firmware: Redo CEC code cleanup 6: Logging changed to VCOS
- firmware: Redo CEC code cleanup 7: Removed hdmi_state_machine_clock_changed
- firmware: Redo CEC code cleanup 8: fixed hdmi state machine clk
- firmware: Redo CEC code cleanup 10: misc cosmetic changes
- firmware: Fixup CEC code cleanup 8: fixed hdmi state machine clk
- firmware: hdmi: Add way of forcing logging for hdmi and cec from boot
- firmware: Redo CEC code cleanup 11: cec_release_logical_addr

- firmware: arm_loader: Respect smsc95xx.macaddr parameter
  See: raspberrypi/linux#1865

- firmware: vec: Fix progressive scan composite mode
  See: #683

- firmware: vec: PAL_M mode is 525/60
  See: #756

- firmware: IL ISP: Support Bayer
- firmware: IL ISP: Fix error in stride calcs for YUYV formats
- firmware: video_render: buffer size fixup for ARGB888

- firmware: video_render: Support per-pixel alpha on RGBA input
  See: waveform80/picamera#199

- firmware: cmake: Expose all symbols from vchostif in bcm_host

- firmware: vec: first field odd should be related to vertical resolution

- firmware: vec: Avoid rolling display with progressive PAL
  See: #683

- firmware: platform: Treat Pi0W like Pi0 w.r.t. clocks and voltages

- firmware: platform: Add final Pi Zero W support

- firmware: GPIO expander: rework so the mailbox service reads raw values
- firmware: arm_loader: Check GPIO direction for low_voltage
  See: raspberrypi/linux#1879

- firmware: warnings: Fix some mostly spurious warnings

- firmware: clock: Calculate PLL multipliers with more precision
- firmware: Set up HDMI VCO same for VEC as for HDMI

- firmeware: gpu_server: Move detailed logging to LOGGING_VMCS_VERBOSE category

- firmware: FXL6408: Remove assert of output state of an input being set

- firmware: ISP tuner/3D: Stop AWB using V3D if disabled from VPU

- firmware: cmake: Install user-vcsm.h to opt/vc/include/interface/vcsm

- firmware: dtoverlay: Make empty alias a valid string
- firmware: dtoverlay: Add dt_node_is_enabled
- firmware: arm_loader: Create simplefb if no /soc/fb
  See: #763

- firmware: isp: Request turbo mode for isp when active
- firmware: isp: Avoid reducing isp clock frequency when initialising

- firmware: gpu_server: unreserve the qpu user shaders at end of each job
- firmware: gpu_server: Only enable/disable qpus at start/end of service connection
@pirquessa

This comment has been minimized.

pirquessa commented Mar 28, 2017

Still no solutions for full transparency area ?

@olagajda

This comment has been minimized.

olagajda commented Jul 4, 2017

Hi,
I am trying to create an overlay that displays a white cross with a transparent background over the camera preview.
I understood that the v.1.13 allows me to do that.
But I can’t make it work.
Here’s the code:

from Tkinter import *
import numpy as np
import picamera
import picamera.array

cameraOK = False

class App:
	def __init__(self, master):
		global o
		if cameraOK == True:
			camera.start_preview()
			a = np.zeros((((922 + 15) // 16) * 16, ((1640 + 31) // 32) * 32, 4), dtype=np.uint8)
			zx = a.shape[1]
			zy = a.shape[0]
			a[zy/2, :, :] = 0xff
			a[:, zx/2, :] = 0xff
			camera.preview.window=(10,72,zx,zy)
			camera.preview.fullscreen = False
			o = camera.add_overlay(np.getbuffer(a),format='rgba', size=(zx,zy), window =(10,72,zx,zy),fullscreen = False)
			o.alpha=64
			o.layer=3
		
def callback():
	if cameraOK == True:
		camera.stop_preview()
		camera.remove_overlay(o)
	root.destroy()
try:
	camera = picamera.PiCamera(resolution=(1640,922))#(1280,720))
	cameraOK = True
	print ('camera ok')
except :
	print('Something went wrong with the camera')	
root = Tk()
root.title('TEST')
root.protocol('WM_DELETE_WINDOW',callback)
w=root.winfo_screenwidth()
h= root.winfo_screenheight()-32
root.geometry("%dx%d+0+0" % (w, h))
app = App(root)

root.mainloop()   

With o.alpha=64 I can see the camera preview but not entirely clear, with the default o.alpha=255 there is no preview visible at all. I only see the cross over a black background, which was the case for the old version but was supposed be changed in the new one.
What am I missing?
Thank you in advance,
Aleksandra

@Reinbert

This comment has been minimized.

Reinbert commented Nov 14, 2017

@olagajda: You missed setting the alpha per pixel. Your array has 4 channels, but apparently you are setting only the first 3.
Try

a[zy/2, :, :, :] = 0xff
a[:, zx/2, :, :] = 0xff

Hope that helps,
Reinbert

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment