Return the ImageData from the Canvas context

[davidshen84]

The WebcamImage object should contain the ImageDate from the canvas' context. So it would be easier to perform pixel-level manipulation on the captured image.

Sample: https://www.w3schools.com/tags/canvas_getimagedata.asp

[basst314]

Hi @davidshen84,

Thanks for raising this, it sounds like an interesting extension. I will read into it and provide an update on this thread soon.

Cheers!

[davidshen84]

https://davidshen84.github.io/#/webcam

Here's a simple application that makes use of this change.

The layout doesn't work well on a small screen.

[basst314]

Hi @davidshen84,

I quickly wanted to provide an update here since my last comment was already a while ago (sorry for that!).

Thanks a lot btw for the pull request!

The extension looks fine and the only concern I have, or thing that I‘d like to investigate a little bit more is to understand the memory implications of this change.

• how large is such a bitmap in memory?
• will it slow down the event firing process to generate that bitmap first?

I thought of maybe introducing a flag where this could be controlled by the developer using the module. To indicate whether or not they want to receive that bitmap, in case its mem or time consumption is significant.

If you have time to do some deep-dive, I‘d highly appreciate it. Otherwise, I‘ll spend some time on it as soon as I get to it.

Thanks!

[davidshen84]

Hi @basst314, 1. The memory size of the ImageData object should be *width * height * 4 *bytes. I think it is a small size for desktop systems, but maybe a bit too much for mobile systems. 2. I think that is hard to determine because it is platform dependent. Theoretically, it only needs to copy the image, which is already in memory, to a new memory location. I think I can add a module level configuration to enable/disable this. What do you think? Thanks, David

…

On Thu, Dec 6, 2018 at 12:26 AM basst314 ***@***.***> wrote: Hi @davidshen84 <https://github.com/davidshen84>, I quickly wanted to provide an update here since my last comment was already a while ago (sorry for that!). Thanks a lot btw for the pull request! The extension looks fine and the only concern I have, or thing that I‘d like to investigate a little bit more is to understand the memory implications of this change. - how large is such a bitmap in memory? - will it slow down the event firing process to generate that bitmap first? I thought of maybe introducing a flag where this could be controlled by the developer using the module. To indicate whether or not they want to receive that bitmap, in case it‘s mem or time consumption is significant. If you have time to do some deep-dive, I‘d highly appreciate it. Otherwise, I‘ll spend some time on it as soon as I get to it. Thanks! — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#30 (comment)>, or mute the thread <https://github.com/notifications/unsubscribe-auth/AAEAzU3pH0s3pYYGj4x7-ogVZLYffHS9ks5u1_PAgaJpZM4YDSHQ> .

[davidshen84]

Hi @basst314 ,

Instead of adding a module level configuration, I decided to add a captureImageData attribute to the component. It's a boolean type value and the default value is false. This makes sure the component is backward compatible, and the developers have instance level control of this object.

Thanks.