June 2019 - Pharo-users - lists.pharo.org

Re: [Pharo-users] How to render video frames?

by Rafael Luque

Thank you Alex! You made my day. Using your suggestion the video is playing more smoothly. Better than that, I've managed the C library to get the frame data from OpenCV in BGRA format in order to be able to use the BlExternalForm, but now I can use directly BGR and save all those alpha bytes. However, I've noticed that if I try to update my custom Bloc element each time a new detected frame is available I get an empty window. Only when I force a small delay (like 5 milliseconds) between frames I can see the video playing in the window. An example of the code I'm running on a Playground would be like the following: detector := OCVBlobDetector createOn: 0. aSpace := BlSpace new extent: 740@580; title: 'OpenCV Frame'. aSpace root background: Color gray asBlBackground. frameElement := (OCVBlocDetectionElement on: detector detect) relocate: 50@50; yourself. aSpace root addChild: frameElement. aSpace show. detector live: [ :detection | frameElement detection: detection. frameElement invalidate. 5 milliSeconds wait. ]. Thank you! El miÃ©., 12 jun. 2019 a las 20:52, Aliaksei Syrel (<alex.syrel(a)gmail.com>) escribiÃ³: > Hi Rafael, > > Assuming you have your OpenCV camera frame object named image in BGR > format (default for OpenCV) > Here is how you can render it at high fps in Bloc (override *BlElement>>#* > drawOnSpartaCanvas: aCanvas in a subclass) > > surface := aSpartaCanvas bitmap > > fromBGR: image imageData > > extent: image width @ image height > stride: image widthStep. > > > aSpartaCanvas fill > > paint: surface; > path: surface bounds; > draw > > > Cheers, > Alex > > > On Wed, 12 Jun 2019 at 22:39, Rafael Luque <rafael.luque.leiva(a)gmail.com> > wrote: > >> Hello, >> >> I'm experimenting with an integration between OpenCV and Pharo based on >> uFFI. My native C library opens a video camera and captures frames for >> detecting certain points (aka blobs) of interest for my use case. The data >> for these frames are available to Pharo as uchar* inside a C struct. >> >> My issues came when I tried to render the video camera frames inside >> Pharo. The C examples I developed for testing the shared library show >> frames around 50-60 fps. However, the best I have got in Pharo is around >> 15-20 fps. >> >> My first try consisted of writing an specific ImageReadWriter for the >> OpenCV image format, so I can build a Form for each frame and render it >> with Morphic. This way I can render the video camera in GTInspector, but at >> a terrible 5-10 fps. >> >> The second try was to use Bloc to render the Forms. I though the Moz2D >> backend will provider better performance. Indeed, I got around 15-20 fps, >> but it is still insufficient for playing video smoothly. >> >> My current try consist of using BlExternalForm to avoid all the frame >> data processing inside Pharo, but I'm finding problems to render this kind >> of "shallow" Forms using Bloc. >> >> I've also find some old mails (2017) about ClÃ©ment Bera working in games >> based on Cairo + SDL. Should I explore this approach for video rendering? >> >> In summary, I don't know what is the recommended approach (if any) to >> show a sequence of video frames with decent bit-rate. >> >> Thank you! >> >

June 13, 2019

Re: [Pharo-users] How to visit over packages, classes, methods (all types)

by Marcus Denker

> On 19 May 2019, at 19:23, Tim Mackinnon <tim(a)testit.works> wrote: > > Hi - is there a way to iterate over all the code in a package (or class or baseline) in a generic way (to pretty print out class definitions, and methods - including extensions ). > > I was kind of hoping that with TonelWriter and Fileout and Critics that we would have a generic visitor mechanism but it seems that all of them just implemented it again - which misses a big opportunity for refactoring so that when you want to reason/print/manipulate code - it would be more straight forward. > > Is there anything/anyone addressing this ? Or maybe Iâve missed an obvious trick somewhere? > I think we always wanted to add some default âvisitorâ style way of iterate over the structureâ¦ I will add this higher on my priorities, because it actually should be quite simple. Marcus

June 13, 2019

Re: [Pharo-users] An IPFS interface for Pharo

by Marcus Denker

> On 13 Jun 2019, at 09:00, Marcus Denker <marcus.denker(a)inria.fr> wrote: > > > >> On 13 Jun 2019, at 08:10, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: >> >> Stephan Eggermont <stephan(a)stack.nl> writes: >> >>>> All of http://files.pharo.org/ ? So how many GB is that? >>> >>> It is only a few thousand changes per release. There is no reason why that >>> shouldnât compress well >> >> Did anybody try? >> >> In IPFS, files are cut into blocks of roughly 256 KB. Blocks shared >> between multiple files are stored only once. So if changes in Pharo >> images from one version to the next happen mainly in one or two specific >> places (such as beginning and end), they would be stored efficiently on >> IPFS without any effort. >> >> But again, the best way to know is to try it out. >> > > Indeed. Another thing to try: if someone has a local IPFS running, would it cache > only those images that either this machine or near machines requested? > > This way we could have one âfullâ copy and caching (e.g. in the âAfrican class roomâ > example) would happen automatically. > > Of course the downside is that one needs to speak the IPFS protocol, thus either running > a client (e.g the go client)â¦ so real transparent use would only be possible if Pharo could > implement the protocolâ¦ There are many other ideas to explore (based on my partial knowledge)â¦ more brainstorming than anything else: - Could we have an image formate that would be âblock friendlyâ? - How could one move resources out of the image into IPFS? - Content addressing (like it is done in Git, too) and Objects, how can it mix? â Could one have âcontent pointersâ instead of âmemory pointersâ? I am sure there is much moreâ¦ Marcus

June 13, 2019

Re: [Pharo-users] An IPFS interface for Pharo

by Marcus Denker

> On 13 Jun 2019, at 08:10, Konrad Hinsen <konrad.hinsen(a)fastmail.net> wrote: > > Stephan Eggermont <stephan(a)stack.nl> writes: > >>> All of http://files.pharo.org/ ? So how many GB is that? >> >> It is only a few thousand changes per release. There is no reason why that >> shouldnât compress well > > Did anybody try? > > In IPFS, files are cut into blocks of roughly 256 KB. Blocks shared > between multiple files are stored only once. So if changes in Pharo > images from one version to the next happen mainly in one or two specific > places (such as beginning and end), they would be stored efficiently on > IPFS without any effort. > > But again, the best way to know is to try it out. > Indeed. Another thing to try: if someone has a local IPFS running, would it cache only those images that either this machine or near machines requested? This way we could have one âfullâ copy and caching (e.g. in the âAfrican class roomâ example) would happen automatically. Of course the downside is that one needs to speak the IPFS protocol, thus either running a client (e.g the go client)â¦ so real transparent use would only be possible if Pharo could implement the protocolâ¦ (all based on a not complete understanding of IPFS) Marcus

June 13, 2019

Re: [Pharo-users] Modeling HABTM

by Christopher Fuhrman

On Thu, Jun 13, 2019, 04:35 Jeff Gray <jeff(a)rogerthedog.com> wrote: > This may not be a very object thing to say but if you have a relational > database with tables for episode, track and play like in Christopher's > diagram, you may not need a class to model play. As it is just a repository > for a set of links I suppose it depends on the requirements for the software. If you wanted to know the start time (relative to the start of the episode) of the Play, that would be an attribute for the class. I might just have a method on an Episode class that calls > the sql to return a collection of Tracks and vice versa. > > > > -- > Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html > >

June 13, 2019

Re: [Pharo-users] An IPFS interface for Pharo

by Konrad Hinsen

Stephan Eggermont <stephan(a)stack.nl> writes: >> All of http://files.pharo.org/ ? So how many GB is that? > > It is only a few thousand changes per release. There is no reason why that > shouldnât compress well Did anybody try? In IPFS, files are cut into blocks of roughly 256 KB. Blocks shared between multiple files are stored only once. So if changes in Pharo images from one version to the next happen mainly in one or two specific places (such as beginning and end), they would be stored efficiently on IPFS without any effort. But again, the best way to know is to try it out. Konrad.

June 13, 2019

Re: [Pharo-users] Modeling HABTM

by sergio ruiz

Oh! i am trying to do everything in pharo/seaside.. i am not using a database at all.. i am working on getting this set up in gemstones, but i am still really confused in that area.. > On Jun 12, 2019, at 10:35 PM, Jeff Gray <jeff(a)rogerthedog.com> wrote: > > diagram, you may not need a class to model play. As it is just a repository > for a set of links I might just have a method on an Episode class that calls > the sql to return a collection of Tracks and vice versa. ---- peace, sergio photographer, journalist, visionary Public Key: http://bit.ly/29z9fG0 #BitMessage BM-NBaswViL21xqgg9STRJjaJaUoyiNe2dV http://www.codeandmusic.com http://www.twitter.com/sergio_101 http://www.facebook.com/sergio101

June 13, 2019

Re: [Pharo-users] Modeling HABTM

by Jeff Gray

This may not be a very object thing to say but if you have a relational database with tables for episode, track and play like in Christopher's diagram, you may not need a class to model play. As it is just a repository for a set of links I might just have a method on an Episode class that calls the sql to return a collection of Tracks and vice versa. -- Sent from: http://forum.world.st/Pharo-Smalltalk-Users-f1310670.html

June 13, 2019

Re: [Pharo-users] How to render video frames?

by Aliaksei Syrel

Hi Rafael, Assuming you have your OpenCV camera frame object named image in BGR format (default for OpenCV) Here is how you can render it at high fps in Bloc (override *BlElement>>#* drawOnSpartaCanvas: aCanvas in a subclass) surface := aSpartaCanvas bitmap fromBGR: image imageData extent: image width @ image height stride: image widthStep. aSpartaCanvas fill paint: surface; path: surface bounds; draw Cheers, Alex On Wed, 12 Jun 2019 at 22:39, Rafael Luque <rafael.luque.leiva(a)gmail.com> wrote: > Hello, > > I'm experimenting with an integration between OpenCV and Pharo based on > uFFI. My native C library opens a video camera and captures frames for > detecting certain points (aka blobs) of interest for my use case. The data > for these frames are available to Pharo as uchar* inside a C struct. > > My issues came when I tried to render the video camera frames inside > Pharo. The C examples I developed for testing the shared library show > frames around 50-60 fps. However, the best I have got in Pharo is around > 15-20 fps. > > My first try consisted of writing an specific ImageReadWriter for the > OpenCV image format, so I can build a Form for each frame and render it > with Morphic. This way I can render the video camera in GTInspector, but at > a terrible 5-10 fps. > > The second try was to use Bloc to render the Forms. I though the Moz2D > backend will provider better performance. Indeed, I got around 15-20 fps, > but it is still insufficient for playing video smoothly. > > My current try consist of using BlExternalForm to avoid all the frame data > processing inside Pharo, but I'm finding problems to render this kind of > "shallow" Forms using Bloc. > > I've also find some old mails (2017) about ClÃ©ment Bera working in games > based on Cairo + SDL. Should I explore this approach for video rendering? > > In summary, I don't know what is the recommended approach (if any) to show > a sequence of video frames with decent bit-rate. > > Thank you! >

June 12, 2019

How to render video frames?

by Rafael Luque

Hello, I'm experimenting with an integration between OpenCV and Pharo based on uFFI. My native C library opens a video camera and captures frames for detecting certain points (aka blobs) of interest for my use case. The data for these frames are available to Pharo as uchar* inside a C struct. My issues came when I tried to render the video camera frames inside Pharo. The C examples I developed for testing the shared library show frames around 50-60 fps. However, the best I have got in Pharo is around 15-20 fps. My first try consisted of writing an specific ImageReadWriter for the OpenCV image format, so I can build a Form for each frame and render it with Morphic. This way I can render the video camera in GTInspector, but at a terrible 5-10 fps. The second try was to use Bloc to render the Forms. I though the Moz2D backend will provider better performance. Indeed, I got around 15-20 fps, but it is still insufficient for playing video smoothly. My current try consist of using BlExternalForm to avoid all the frame data processing inside Pharo, but I'm finding problems to render this kind of "shallow" Forms using Bloc. I've also find some old mails (2017) about ClÃ©ment Bera working in games based on Cairo + SDL. Should I explore this approach for video rendering? In summary, I don't know what is the recommended approach (if any) to show a sequence of video frames with decent bit-rate. Thank you!

June 12, 2019