[Ssc-dev] quick note on Carrie's work
Harlo Holmes
harlo at guardianproject.info
Sat Aug 24 09:18:54 EDT 2013
I've created a ticket for myself to make sure I do the proper
smoke-testing: https://dev.guardianproject.info/issues/1772
++++++++++++++++++++++++++
Research Fellow, Head of Metadata
The Guardian Project <https://guardianproject.info>
pgp: 0xA4469630
twitter: @harlo
On Sat, Aug 24, 2013 at 9:16 AM, David Oliver <david at olivercoady.com> wrote:
> I'm thrilled to hear this, and have visions of little JQuery animations
> dancing in my head.
>
> Carrie, we'll talk soon.
>
> David M. Oliver | david at olivercoady.com | http://olivercoady.com |
> http://dmo.tel | @davidmoliver | +1 970 368 2366
>
>
> On Sat, Aug 24, 2013 at 9:02 AM, Harlo Holmes <harlo at guardianproject.info>wrote:
>
>> So far, it's worked this way:
>>
>> When our user clicks the camera button, they're directed to InformaCam's
>> camera-management activity, which before launching the user's camera,
>> starts up our sensors and starts a log for those sensor readings. Once
>> this log is created, and all the sensors have started up and are
>> successfully logging, the user is passed to their on-board camera app. As
>> the user takes their photos/videos, each new media item is packaged with a
>> reference to the sensor log file for later. FInally, when the user exits
>> the on-board camera activity, they're brought back to our custom activity
>> which shuts down the sensors, and seals the logs.
>>
>> So, if a researcher wanted to gauge a user's movement as they took a
>> photo or video, that researcher already has several seconds of sensor data
>> captured before capture, during capture, and after capture; it's up to the
>> researcher (us? j3m-scan!) to properly window that data.
>>
>> As for resolution, currently, its resolution is not fine enough, as Hans
>> notes. Accelerometer and gyroscope etc currently have a sample rate of
>> 500ms. However, this can be changed very easily because the rate at which
>> each sensor logs is set in a config file and it's a matter of changing that
>> long (and making sure we don't run into out-of-memory errors because of the
>> increased number of data points.) I'm not too concerned about battery
>> life, though, because it's not as if the sensors are running continuously
>> as you use the app; this only happens while the user is making media, which
>> is a relatively short duration. Also, the android sensor API is optimized
>> for gaming, so it should be fine for this minimal use case.
>>
>> Thanks,
>> Harlo
>>
>> ++++++++++++++++++++++++++
>> Research Fellow, Head of Metadata
>> The Guardian Project <https://guardianproject.info>
>>
>> pgp: 0xA4469630
>> twitter: @harlo
>>
>>
>> On Fri, Aug 23, 2013 at 4:42 PM, David Oliver <david at olivercoady.com>wrote:
>>
>>> I think there's a technology side and a "user scenario" side to this -
>>> and I don't want this to be treated like an open-ended problem/issue.
>>>
>>> Here's the scenario I want to "solve": A photograph is a snapshot of a
>>> scene in time. So, for photographs, we need the metadata to align with
>>> that moment in time. I can imagine that most metadata we're tracking can
>>> also be "snapshotted". BUT, with the accelerometer, the snapshot (single
>>> reading) is useless - you need more than one reading to show a
>>> delta/change. While you could track accelerometer every 1/10 second, say,
>>> and then store readings in a circular queue (of, say, the last 10 seconds),
>>> that continuous reading would drain the device's battery. But, to be
>>> valid, the readings have to be in the same timeframe as the photo.
>>> So,.....open question.
>>>
>>> I suppose this is easier for video since you've got a start/stop time
>>> (and OS event, likely) allowing you to start/stop accelerometer capture.
>>>
>>> I think if we have geo-position, compass, and accelerometer then you
>>> make a nice graphic depiction of positionality and motion at time of
>>> capture.
>>>
>>> Dave
>>>
>>> David M. Oliver | david at olivercoady.com | http://olivercoady.com |
>>> http://dmo.tel | @davidmoliver | +1 970 368 2366
>>>
>>>
>>> On Fri, Aug 23, 2013 at 3:09 PM, Nathan of Guardian <
>>> nathan at guardianproject.info> wrote:
>>>
>>>> Adding Harlo to this thread, and cc'ing the list, as this is an
>>>> important general topic.
>>>>
>>>> On 08/23/2013 03:06 PM, David Oliver wrote:
>>>> > Here's one thing I want to know to aid in this process: As I
>>>> understand
>>>> > it, having a single accelerometer reading is useless for determining
>>>> > anything about movement, it is the comparative readings that are
>>>> important.
>>>> > Using, say, 3 readings, you could assert something about motion.
>>>> But,
>>>> > InformaCam does not know "I should collect an accelerometer reading
>>>> just
>>>> > before the picture is taken, then one during, then one after - since
>>>> it
>>>> > does not know when media is created. Yet, you can't possibly gather
>>>> > accelerometer (and/or compass) in real time all the time and then
>>>> wait to
>>>> > use it.......so what does InformaCam actually do?
>>>> The question is then, how/when are we logging accelerometer data, and
>>>> what can or should we infer from it?
>>>>
>>>> _______________________________________________
>>>> Ssc-dev mailing list
>>>>
>>>> Post: Ssc-dev at lists.mayfirst.org
>>>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>>>
>>>> To Unsubscribe
>>>> Send email to: Ssc-dev-unsubscribe at lists.mayfirst.org
>>>> Or visit:
>>>> https://lists.mayfirst.org/mailman/options/ssc-dev/david%40guardianproject.info
>>>>
>>>> You are subscribed as: david at guardianproject.info
>>>>
>>>
>>>
>>> _______________________________________________
>>> Ssc-dev mailing list
>>>
>>> Post: Ssc-dev at lists.mayfirst.org
>>> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>>>
>>> To Unsubscribe
>>> Send email to: Ssc-dev-unsubscribe at lists.mayfirst.org
>>> Or visit:
>>> https://lists.mayfirst.org/mailman/options/ssc-dev/harlo.holmes%40gmail.com
>>>
>>> You are subscribed as: harlo.holmes at gmail.com
>>>
>>>
>>
>
> _______________________________________________
> Ssc-dev mailing list
>
> Post: Ssc-dev at lists.mayfirst.org
> List info: https://lists.mayfirst.org/mailman/listinfo/ssc-dev
>
> To Unsubscribe
> Send email to: Ssc-dev-unsubscribe at lists.mayfirst.org
> Or visit:
> https://lists.mayfirst.org/mailman/options/ssc-dev/harlo.holmes%40gmail.com
>
> You are subscribed as: harlo.holmes at gmail.com
>
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: <http://lists.mayfirst.org/pipermail/ssc-dev/attachments/20130824/6a41b342/attachment.html>
More information about the Ssc-dev
mailing list