qreator-discuss team mailing list archive

[Stefan Schwarzburg <stefan.schwarzburg@xxxxxxxxx>]

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.


> - 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.


> - 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...


> - 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
>
>