OK, I'm going to wait the 0.2.0 release of OcempGUI in order to test it.
Maybe you can send an email onto this mailing list in order to announce that it is release.

To answer your question, I get pictures directly from USB camera.

I have tested the solution of created a "kinf of" widget that run in a different thread and blit pictures directly to the screen. It works great, because I blit a picture as soon as I have got a picture. But this widget is not an Ocemp GUI at all.

The problem with my first attempt (building a real Ocemp Video Widget) is that the update method of this module is called only once. Indeed the Frame object that contains it, never call the update function of its children because it is himself marked as clean (dirty=False).
I'd like to know where have I done a mistake.
I give you the source of my new Widget at the end of the email
I call it like this
    re = widgets.Renderer()
    re.create_screen (1024, 768) # Creates the pygame window
    #page = Page4()
    frame = widgets.HFrame()
    cam = uEyeAPI.uEyeAPI()

Thanks in advance for your help.


#################Source code of my Widget###########################3
class uEyeAPI(BaseWidget):

        def __init__(self):
            # Initialization of the uEye API library
            self.libuEye = ctypes.cdll.LoadLibrary( "/home/x86/workspace/RSX+/img.acq/img.acquisition.Lib/uEyeAPI.so")
            self.libuEye.GetImageSize.restype = ctypes.c_int
            #self.libuEye.GetImage.argstypes = []

            #PyGame module initialization
            #       pygame.init()

        def InituEye(self):
            ret = self.libuEye.InituEye ()
            if (ret != True):
                return False
            self.BufSize = self.libuEye.GetImageSize()
            print "Buffer size of uEye Camera images = ",self.BufSize
            self.pBuffer = ctypes.create_string_buffer(self.BufSize)
            print len(self.pBuffer.raw)
            del self._image
            self._image = pygame.image.frombuffer(self.pBuffer.raw,(640,480),'RGB')
            self._rect = self._image.get_rect ()
            self.now = time.time()
            self.last = self.now
            self.delay = 0
            self.nbAcq = 0
            #self.Buffer = pygame.surfarray.array2d(PySurf)
            #self.pBuffer = ctypes.byref(self.Buffer)
            #self.Buffer = array('d',range(self.BufSize))  #ctypes.c_buffer("\000", self.BufSize)
            #(self.pBuf , length) = self.Buffer.buffer_info()

        def ExituEye(self):
            return self.libuEye.ExituEye()

        def GetPicture(self,surface):
            if self.libuEye.GetImage(surface.pixels()) == True:
                self.nbAcq += 1
                if self.nbAcq == 100:
                    self.now = time.time()
                    self.delay = (self.now - self.last)/self.nbAcq
                    self.last = self.now
                    self.nbAcq = 0
                    print "Delay in image acquisition %f" % self.delay
                    self.delay = 1/self.delay
                    print "Acquired Framerate is %f" % self.delay
                return True
            return False

        def update (self, *args):
            if self._image:
                    self.dirty = True
                    return True
                return False

        def draw(self):
            return self._image

2006/6/27, Marcus von Appen < marcus@sysfault.org>:
On, Tue Jun 27, 2006, Bertrand CACHET wrote:

> Hi all,
> I'm currently using ocempGUI widgets to develop the GUI of my software.
> I need to develop a new widget in which I display video which come from an
> USB camera.

Wow, this sounds really interesting. So does it read directly from the
device or are you loading the camera as a removable filesystem?

> I have developed one which acquire the image into the update method and blit
> it during the draw method.
> But I was forced to modify the widget that contains it because of the dirty
> flag. Indeed, even if my Video widget indicates that it is dirty, its
> container doesn't take care about it.
> Is it normal ? Or does I miss something.

This depends on your code. Without it, it's really hard to say, where a
possible mistake was made (be it in OcempGUI or in your widget).

> I was thinking about creating a new version of my widget which may create a
> new thread that will send messages to the Renderer. The renderer will treat
> the message by displaying the new image. The advantage of this method is
> that anytime I have got a new image, it will be displayed, but the structure
> of my new widget may be completely different than existing one.

The rendering will completely change in OcempGUI 0.2.0, so that widget
changes are usually applied instantly. This has both, advantages and
disadvantages, but I won't go into details here for now as a pre-release
of it is scheduled for this week.
However, self-made widgets, which fit the 0.1.x rendering structure will
not work under 0.2.0 without various changes.

> Next step is to modify the rendering of the widgets using Cairo library.
> Followinf advices find onto the Ocemp website, I only need to modify Style
> module. Is it always true, or have you any over advices ?

This is true for 0.1.x and will be partly true for 0.2.0. Some widgets
however do some additional drawing in their draw() method in 0.1.x.
0.2.0 will be completely different here. Backgrounds (and only those)
will be drawn by the Style class (or better: its attached engine),
while the rest of the drawing is usually done in the widget's draw()

I did not look at the advantages of cairo for now and am not sure how
well it works with SDL, but basically you should be able to rework the
Style methods to make use of it.


Using Tomcat but need to do more? Need to support web services, security?
Get stuff done quickly with pre-integrated technology to make your job easier
Download IBM WebSphere Application Server v.1.0.1 based on Apache Geronimo

ocemp-devel mailing list