qreator-discuss team mailing list archive

[Stefan Schwarzburg <stefan.schwarzburg@xxxxxxxxx>]

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


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


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

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