qreator-discuss team mailing list archive

[David Planella <david.planella@xxxxxxxxxx>]

On Sat, Jun 15, 2013 at 10:59 AM, Stefan Schwarzburg <
stefan.schwarzburg@xxxxxxxxx> wrote:

> Hi David,
>
> On Thu, Jun 13, 2013 at 10:00 PM, David Planella <
> david.planella@xxxxxxxxxx> wrote:
>
>> On Mon, Jun 10, 2013 at 10:43 PM, Stefan Schwarzburg <
>> stefan.schwarzburg@xxxxxxxxx> wrote:
>>
>>> Hi
>>>
>>> On Mon, Jun 10, 2013 at 9:51 PM, David Planella <
>>> david.planella@xxxxxxxxxx> wrote:
>>>
>>>> On Mon, Jun 10, 2013 at 5:24 PM, Stefan Schwarzburg <
>>>> stefan.schwarzburg@xxxxxxxxx> wrote:
>>>>
>>>>> Hi David,
>>>>>
>>>>>  Thanks for the testing. From the size of the images and the picture,
>>>>>> I assume you took those from the desktop.
>>>>>>
>>>>>>
>>>>> True. I do not have any mobile that runs ubuntu :-(
>>>>>
>>>>>
>>>>
>>>> No worries. I cannot offer a phone, as I only got one myself, but let
>>>> me know if you have any snippet or branch you'd like me to test on a device.
>>>>
>>>>
>>>>> In my case, playing with exposure, white balance or brightness did not
>>>>>> make any difference when pictures were taken from the web cam. So we've got
>>>>>> two cases here: in my case images are too dark, and in your case images go
>>>>>> crazy. I think I share your conclusion that the camera settings *on the
>>>>>> desktop* are not very reliable at the moment.
>>>>>>
>>>>>>
>>>>> I'm actually not sure that they are always too dark on your phone as
>>>>> well. Maybe 5 out of 500 pictures were bright on my desktop, did you try
>>>>> that many on your phone? I have used automatic triggering, you can copy the
>>>>> code from my branch. Let it run for 15 minutes or so and then check your
>>>>> images for bright ones... :-)
>>>>>
>>>>>
>>>>
>>>> I still believe there is a difference between desktop and mobile, both
>>>> at the hardware level (e.g. my webcam does not support autofocus, whereas
>>>> the Nexus' one does) and at the software level (GStreamer-based plugin on
>>>> the desktop vs something else -I've not figured out yet what- on the Nexus).
>>>>
>>>> The automatic triggering is a really good idea. But eaven without doing
>>>> automatic triggering, for the ~30 or so pictures I've taken manually on the
>>>> desktop and on the device, the pictures are invariably always dark on the
>>>> desktop, and always ok on the device.
>>>>
>>>> If you've got the automatic triggering code somewhere, I'll give it a
>>>> shot on the device, but we should probably decouple it from Qreator and use
>>>> it as a separate test app.
>>>>
>>>>
>>> Sure, the code is here:
>>> lp:~stefan-schwarzburg/qreator/touch-scanner-automaticscan
>>>
>>
>> Thanks!
>>
>>
>>>
>>>>
>>>>>> I'm not sure how we can correct that. In my case, it seemed that the
>>>>>> webcam ignored the settings, so it might be that either the hardware does
>>>>>> not support them, or that the camera plugin for the desktop is not passing
>>>>>> the parameters correctly. Which is weird, as the Qt camera plugin uses
>>>>>> GStreamer as a backend afaik, and Cheese, which also uses GStreamer, takes
>>>>>> pictures with the right brighthness.
>>>>>>
>>>>>
>>>>> Well, the viewfinder is always totally fine, one the still images are
>>>>> not.
>>>>> I also noted, that you do not use camera.searchAndLock() "Start
>>>>> focusing, exposure and white balance calculation." Maybe this mixes up
>>>>> exposure for viewfinder and still image...
>>>>> It would be great to directly get the image from the viewfinder
>>>>> instead of taking a picture...
>>>>>
>>>>
>>>> Yeah, I'm not sure if it's possible, though. In any case, in the (I
>>>> must admit) very limited photography knowledge I have, I always assumed
>>>> that the exposure is longer on the video preview, which is why the pictures
>>>> always look ok on the preview. Now this might be a totally wrong
>>>> assumption, though...
>>>>
>>>> I'll give a shot at searchAndLock(), but I'm a bit disappointed to see
>>>> that at least on the desktop the Camera component is not as plug-and-play
>>>> as the documentation leads to believe....
>>>>
>>>>
>>>>>
>>>>>
>>>>>>
>>>>>> In my testing on a device, the white balance/brightness/exposure seem
>>>>>> correct, so this issue apparently only affects the desktop version.
>>>>>>
>>>>>
>>>>> Well, if your images are too dark, then exposure is not ok!
>>>>>
>>>>>
>>>>
>>>> Right, but the point is that images are never dark on the device, only
>>>> on the desktop.
>>>>
>>>>
>>>>>
>>>>>> Another issue that I've now got more insight on is the delay in
>>>>>> decoding from a device. It takes about 15-20 seconds to decode a QR code,
>>>>>> but in the limited testing that I've done it seems to work every time,
>>>>>> which is really good.
>>>>>>
>>>>>
>>>>> For me it worked everytime the brightness was ok.
>>>>>
>>>>>
>>>>
>>>> Yeah, on the desktop, if I point a bright light at the QR code, the
>>>> decoding takes about 1s, which is optimal. On the device, it takes these
>>>> 15-20 seconds, which I assume to be due to the additional time it takes to
>>>> process a higher resolution picture.
>>>>
>>>> On the desktop the resolution of my captures is 640x480
>>>> On the device I'll have to check when it's finished charging, but I'm
>>>> pretty certain it's a very high resolution.
>>>>
>>>> Which resolution do you have on your webcam?
>>>>
>>>
>>> Format Video Capture:
>>>         Width/Height  : 640/480
>>>         Pixel Format  : 'YUYV'
>>>         Field         : None
>>>         Bytes per Line: 1280
>>>         Size Image    : 614400
>>>         Colorspace    : SRGB
>>>
>>>
>>
>> Yeah, similar to my cam. Resolution on the device's cam is 3264x1836px.
>>
>>
>>>
>>>>
>>>>>> I believe what might be happening here is that it takes quite a lot
>>>>>> of memory or processing power to scan and decode the images with higher
>>>>>> resolution from the device's camera (on my desktop it takes about 1 second
>>>>>> to decode the webcam's 640x480 images).
>>>>>>
>>>>>
>>>>> You could try to move a desktop-webcam picture and let it scan on the
>>>>> mobile (hardcoded), just to see the time difference. But sure, higher
>>>>> resolution should increase the time drastically.
>>>>>
>>>>>
>>>>
>>>> Yeah, that's a good idea. I've also thought of implementing a very
>>>> rough shot of your image-loading feature and get the desktop load a capture
>>>> from the device. I think I will try that next.
>>>>
>>>> I really want to nail this one down. We can work the workflow in
>>>> Balsamiq in parallell, but I'd really like to get the basics of capturing
>>>> and decoding right and solid.
>>>>
>>>
>>> Sure, anything I should work on  so that we do not work on the same
>>> things?
>>>
>>>
>>
>> I think whatever you find more interesting or more fun :)
>>
>> In any case, I've got a few suggestions if you'd be interested in any of
>> them. I think if I can spend a couple of hours on it tonight, I'll try to
>> work on getting the C++ plugin to work on a device, make it more
>> user-friendly and get the automated scanning feature to work.
>>
>> Here are the suggestions:
>>
>> - Fixing camera exposure on the desktop
>>
>
> While it does not sound fun, I think its important, so I will start with
> this.
>
>

Yeah, not my idea of fun, either, but I agree it's important. Thanks for
looking into this.

I looked at it a bit a few days ago, and I found a Qt/QML camera project
which I tested to see the result of image captures. It's called kamerka and
it's packaged for Ubuntu as well. In my webcam, the exposure was correct
for all captures (i.e. they weren't dark, or at least not darker than the
video preview). I looked at the code to see if I could find out how they
did it, but unfortunately it seems they're not using the Camera component:

https://github.com/dos1/kamerka


> - Video output size (I'm not sure how to best scale the video output,
>> especially on desktop when resizing the window. I think it should be
>> anchored to the top and grow to fill the window's width while keeping the
>> aspect ratio, but I'm not too sure yet - any ideas?).
>>
>
> I guess we should downscale but not upscale, but always show the full
> image. And I would center it vertically and horizontally.
> Keeping the aspect ratio is a must...
> Maybe we should test the different anchor positions and decide afterwards.
>
>

Yeah, I agree.


> - Stopping cam when switching tabs, when the decoding dialog is shown, and
>> when app does not have the focus (the latter is already implemented in the
>> camera-app in Ubuntu)
>>
>
> Just let me know when you start with that one, and I will do the same...
>
>

I've just started on this, I'm using this snippet, but it's not yet playing
well with the overlay with the square to show the area of capture yet, and
it deactivates the camera on resize, which is not something we really want,
as the UI then seems laggy:

Connections {
        target: Qt.application
        onActiveChanged: (Qt.application.active) ? camera.start() :
camera.stop()
    }

I'll keep researching on this one.

I've now updated the lp:~dpm/qreator/touch-scanner branch by merging the
reorganized source tree layout from the main lp:qreator/touch series. I've
also added a Decoder component to abstract the decoding backend and be able
to switch between JavaScript and C++. It's not functional yet, as the JS
backend seems to have some issues with loading the image from the internal
Canvas component in the new Decoder components, but I'll keep trying ;)

Cheers,
David.

- Anything else that makes the scan view more usable :)
>>
>> Cheers,
>> Stefan
>>
>>
>
>> Cheers,
>> David.
>>
>>
>>> Cheers,
>>> Stefan
>>>
>>>
>>>>
>>>>>
>>>>>> I'll try to benchmark if the C++ plugin can do this much faster, but
>>>>>> in any case, a couple of measures I can think of are:
>>>>>>
>>>>>> ~ Reduce the resolution of the captured image
>>>>>> ~ Crop the captured image to the QR code window before sending it to
>>>>>> the decoding library functions
>>>>>>
>>>>>>
>>>>>> In terms of the QR code window, I've started adding some preliminary
>>>>>> code to show where the QR code should be positioned in the picture to be
>>>>>> scanned, but it's not yet functional (i.e. the window is shown, but it does
>>>>>> not do anything).
>>>>>>
>>>>>>
>>>>> The new window looks very nice!
>>>>> And I have seen that you added the dialogs, with an even better
>>>>> "dynamc text" mechanism :-) Nice!
>>>>>
>>>>>
>>>> Not sure if better, just an alternative :). I've now answered the
>>>> question on Ask Ubuntu with the solution. Thanks for your answer! :)
>>>>
>>>> Cheers,
>>>> David.
>>>>
>>>>
>>>>> Cheers,
>>>>> Stefan
>>>>>
>>>>>
>>>>>> I've updated the code on the scanner branch:
>>>>>> lp:~dpm/qreator/touch-scanner
>>>>>>
>>>>>> Cheers,
>>>>>> David.
>>>>>>
>>>>>> --
>>>>>> Mailing list: https://launchpad.net/~qreator-discuss
>>>>>> Post to     : qreator-discuss@xxxxxxxxxxxxxxxxxxx
>>>>>> Unsubscribe : https://launchpad.net/~qreator-discuss
>>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>>
>>>>>>
>>>>>
>>>>> --
>>>>> Mailing list: https://launchpad.net/~qreator-discuss
>>>>> Post to     : qreator-discuss@xxxxxxxxxxxxxxxxxxx
>>>>> Unsubscribe : https://launchpad.net/~qreator-discuss
>>>>> More help   : https://help.launchpad.net/ListHelp
>>>>>
>>>>>
>>>>
>>>
>>> --
>>> Mailing list: https://launchpad.net/~qreator-discuss
>>> Post to     : qreator-discuss@xxxxxxxxxxxxxxxxxxx
>>> Unsubscribe : https://launchpad.net/~qreator-discuss
>>> More help   : https://help.launchpad.net/ListHelp
>>>
>>>
>>
>> --
>> Mailing list: https://launchpad.net/~qreator-discuss
>> Post to     : qreator-discuss@xxxxxxxxxxxxxxxxxxx
>> Unsubscribe : https://launchpad.net/~qreator-discuss
>> More help   : https://help.launchpad.net/ListHelp
>>
>>
>
> --
> Mailing list: https://launchpad.net/~qreator-discuss
> Post to     : qreator-discuss@xxxxxxxxxxxxxxxxxxx
> Unsubscribe : https://launchpad.net/~qreator-discuss
> More help   : https://help.launchpad.net/ListHelp
>
>