Overview of approaches to use MUSE to enable receiving cell phone images in installation
b
In case the subject got cut off here it is again:
Overview of approaches to use MUSE to enable receiving cell phone
images in installation.
I'm working on a muse3 commission application and have a few technical
questions. I've looked over the wiki and documents on the website but
I'm new to cell technology and still unsure how it works.
The technical task is simple enough, allow people to send images from
phones to a PC in an installation.
It should require the least (preferably none) development on the cell
side, so that images could get sent to the system as easier as images
are sent between friends. Ideally any camera phone could be used, but
kate mentioned that a phone with internet access (gsm?) would be
required.
What is technically required to get such a system working with muse3?
As far as I can tell images can only be transferred in two ways, MMS
and via internet. Which is more common and more often used?
Via MMS it seems the installation PC would require a connected cell
phone so that images submitted to a particular number could be
transferred (via usb?) to the PC.
If the images may only be transferred by the internet then does the PC
require a web-server to manage a website which retrieves the images?
Another option would be sending the images through an email address
but that appears just as complex as the web-server, in terms of
development.
So what is the simplest system to accomplish this? Allow as many
potential contributers to send content as easy (and standard) as
possible. Receive these images and transfer them (as jpegs likely) to
a PC? This seems related to REST.
I'm planning to read the images using Pure Data to create something
similar to: http://www.ekran.org/ben/wp/?p=227
FYI my artistic practice is based in FLOSS and so the installation
machine would be running Linux.
Thanks for your time,
B. Bogart
Jim Udall
MMS interface already present there.
In terms of your own application, the platform would receive the MMS then
deliver it to your application (presumably running on your computer) via an
HTTP POST. If you're at all familiar with web programming this is a very
simple interface methodology. So "No -you don't need a PC with a connected
cell phone". You just need a PC with an internet connection.
Now what you do with the image as you've received it is entirely up to you
at this point.
As for e-mail.... we do not yet have an e-mail avenue for allowing mobile
users to upload images - although I believe that will be implemented in some
fashion as part of the social media aggregation services we are offering.
Now for my editorialization on your questions:
MMS is far and away the easiest method for end users to deliver pictures and
videos to applications. However, there are a number of serious caveats of
which you should be aware:
1. The MMS implementation in the MUSE platform is based on a GSM modem. As
a result, the thruput is VERY slow. You'll be lucky to get 2 MMS per minute
out of it. MUSE is an experimental research platform so I don't apologize
for this limitation. I believe MMS has a role to play in user generated
content from the mobile space, but the reality is that carriers in Canada
are just not positioning any technology to do this on a large scale. It is
my opinion that this will evolve (as it already has done so in other
countries).
2. Currently our MMS gateway is inoperative (effective the beginning of
this week). It's a long story why that is the case. I hope to have it up
again by the end of this month.
3. Carriers restrict the maximum size of MMS messages users can deliver.
This is typically on the order of 300K. This restriction may or may not be
a problem for you application - depending on what you want to do.
e-mail from a mobile phone has the advantage of overcoming the size
restriction on content as well as the scalability issue. However it suffers
from a number of problems:
1. Handset makers make it VERY simple to send a picture as an MMS. Handset
makers in general don't make it nearly so simple to send a picture as an
e-mail.
2. Everyone can send an MMS. Only those who have been successful in
setting up e-mail from their mobile devices are able to send e-mail. I'm
EXTREMELY technically knowledgeable in this area and even I have been
unsuccessful in setting up my phone to work to work with my e-mail server.
3. Pricing for MMS is predictable - and now affordable. Without a plan, it
typically cost a user about $.50 per picture. A Fido messaging plan for
example however allows 1000 MMS and 2500 SMS messages for $20/month. So
worst case a user spends $.50 to send a picture - at least he knows what the
cost is. E-mail however uses standard data rates. Without a data plan these
rates are about $.03/kbyte. So to send a 300K picture via e-mail with no
plan, it will cost the user about $9 - versus $.50 per MMS. Of course there
are now e-mail plans available. Again how many users have e-mail plans
though.
There is another option available to you (which I don't recommend).
Specifically you could write a J2ME application that interfaces to the
camera and allows pictures captured to communicate directly with your
application - bypassing the MUSE platform entirely. This solution has the
following limitations:
1. Users would have to install the J2ME application on their device before
using your solution. Most users haven't a clue how to do that.
2. Not all J2ME implementations provide access to camera resources. Your
app may or may not work on all camera phones.
3. To make the application practical, you would have to become a trusted
J2ME application - which costs some money. Otherwise untrusted applications
have trouble setting up data sessions back to your application.
4. You data traffic would travel over the carrier's data network. That
means the content would be billed at the rate of $.03/kbyte. Even carriers
with unlimited browsing/e-mail plans don't cover this sort of traffic with
those plans. The cost to the enduser would be significant.
I hope this answers your questions.
Jim Udall
Technology Director Mobile MUSE
102-577 Great Northern Way
Vancouver, BC
V5T 1B1
+1-604-716-1523
b
Thanks for taking the time to answer my questions. Inline are a few
follow-up comments.
> In terms of your own application, the platform would receive the MMS then
> deliver it to your application (presumably running on your computer) via an
> HTTP POST. If you're at all familiar with web programming this is a very
> simple interface methodology. So "No -you don't need a PC with a connected
> cell phone". You just need a PC with an internet connection.
clarify:
1. Cell user uses MMS to send image to another cell phone (the one
used for the installation)
2. That second cell phone is running a MUSE application which routes
incoming MMS images to HTTP post on a web-server running on the
installation computer (or somewhere else).
3. The installation computer receives the images via post and which is
then opened in Pure Data.
So if the cell is not connected to the PC, then there needs to be a
cell phone that acts as a router for all the incoming MMS messages. Is
this what the "mms gateway" does?
Could a cell be configured to dump all incoming MMS images to flash
memory, which would be mounted via USB mass storage so the files could
be easily transferred to the installation computer?
I agree the email and java solutions seem more awkward.
> 1. The MMS implementation in the MUSE platform is based on a GSM modem. As
> a result, the thruput is VERY slow. You'll be lucky to get 2 MMS per minute
> out of it. MUSE is an experimental research platform so I don't apologize
> for this limitation. I believe MMS has a role to play in user generated
> content from the mobile space, but the reality is that carriers in Canada
> are just not positioning any technology to do this on a large scale. It is
> my opinion that this will evolve (as it already has done so in other
> countries).
1280x1024 at the absolute maximum. The proposal is more about many
people sending images, not the same person sending many images.
> 2. Currently our MMS gateway is inoperative (effective the beginning of
> this week). It's a long story why that is the case. I hope to have it up
> again by the end of this month.
> 2. Everyone can send an MMS. Only those who have been successful in
> setting up e-mail from their mobile devices are able to send e-mail. I'm
> EXTREMELY technically knowledgeable in this area and even I have been
> unsuccessful in setting up my phone to work to work with my e-mail server.
> 3. Pricing for MMS is predictable - and now affordable. Without a plan, it
> typically cost a user about $.50 per picture. A Fido messaging plan for
> example however allows 1000 MMS and 2500 SMS messages for $20/month. So
> worst case a user spends $.50 to send a picture - at least he knows what the
> cost is. E-mail however uses standard data rates. Without a data plan these
> rates are about $.03/kbyte. So to send a 300K picture via e-mail with no
> plan, it will cost the user about $9 - versus $.50 per MMS. Of course there
> are now e-mail plans available. Again how many users have e-mail plans
> though.
Are people used to spending 50c when they want to do something, or is
it more used in special circumstances? I'm not sure there is
sufficient "payoff" in this proposal to warrant people spending money
to contribute.
To give you some context the project is a cell-phone enabled version
of this:
http://www.ekran.org/ben/wp/?p=227
Where images could be contributed from the cell phones in the context,
rather than being just from the live camera.
Thanks for your advice.
B. Bogart
Jim Udall
Jim
-----Original Message-----
From: muse3-p...@googlegroups.com
[mailto:muse3-p...@googlegroups.com] On Behalf Of b
Sent: Saturday, August 09, 2008 10:49 AM
To: MUSE3 Platform
Subject: Re: Overview of approaches to use MUSE to enable receiving cell
phone images in installation
Hello Jim,
Thanks for taking the time to answer my questions. Inline are a few
follow-up comments.
> In terms of your own application, the platform would receive the MMS then
> deliver it to your application (presumably running on your computer) via
an
> HTTP POST. If you're at all familiar with web programming this is a very
> simple interface methodology. So "No -you don't need a PC with a
connected
> cell phone". You just need a PC with an internet connection.
What is the "platform"? Muse running on a particular cell phone? To
clarify:
-----------------------
MUSE platform is a hosted service available at developers.mobilemuse.ca that
offers a number of features and capabilities. Those services and features
are intended to be useful in deploying network base mobile applications.
Some services are low level and offered as SOAP or REST accessed web
services. Others are packaged as components or applications - configurable
and useable via any web browser. Among the low level services offered by
the platform or bi-directional text messaging and bi-directional MMS
messaging. How SMS or MMS is actually implemented is of no concern to you
as a developer. This is important since especially for SMS, there are a
variety of means to affect services. You as the developer need not concern
yourself with how these services are affected. Indeed, that is one of the
goals of the platform.
--------------------------------------
1. Cell user uses MMS to send image to another cell phone (the one
used for the installation)
2. That second cell phone is running a MUSE application which routes
incoming MMS images to HTTP post on a web-server running on the
installation computer (or somewhere else).
3. The installation computer receives the images via post and which is
then opened in Pure Data.
So if the cell is not connected to the PC, then there needs to be a
cell phone that acts as a router for all the incoming MMS messages. Is
this what the "mms gateway" does?
-----------------------------------------------
The MMS Gateway is a subsystem of the MUSE platform.
---------------------------------
Could a cell be configured to dump all incoming MMS images to flash
memory, which would be mounted via USB mass storage so the files could
be easily transferred to the installation computer?
-------------------------------------------
Understand that this is not something of even remote interest to MUSE
platform. However, if you want to explore this possibility yourself...
Nokia phones (like all cell phones), can be configured to automatically
accept incoming MMS messages (ala SMS). Nokia software I believe allows you
to connect your phone to a PC and copy over the MMS messages. You would
then have to parse these MMS messages (exercise left to the reader), to
extract the pertinent content.
---------------------------------------------
I agree the email and java solutions seem more awkward.
> 1. The MMS implementation in the MUSE platform is based on a GSM modem.
As
> a result, the thruput is VERY slow. You'll be lucky to get 2 MMS per
minute
> out of it. MUSE is an experimental research platform so I don't apologize
> for this limitation. I believe MMS has a role to play in user generated
> content from the mobile space, but the reality is that carriers in Canada
> are just not positioning any technology to do this on a large scale. It
is
> my opinion that this will evolve (as it already has done so in other
> countries).
What is the bit-rate of the gsm modem? I'm expecting images at
1280x1024 at the absolute maximum. The proposal is more about many
people sending images, not the same person sending many images.
----------------------------------------------------
Bit rates are pretty much irrelevant. MMS is exchanges using standard
EVDO/1X/GPRS/EDGE packet data networks. There are of course raw bit rates
for all these technologies, but over wireless, any discussion of bit rates
is meaningless because of issues such as air performance and cell capacity.
Not to mention the cost of establishing and tearing down packet data calls.
IN some sense, on some phones, the sender has more control over the size of
MMS messages. Nokia for example allows you to configure MMS to send
small/medium or large pictures. This is not a universal statement.
And BTW, a notable exception to the ubiquity of MMS is the iPhone. It does
NOT support sending or receiving of MMS.
-----------------------------------------
> 2. Currently our MMS gateway is inoperative (effective the beginning of
> this week). It's a long story why that is the case. I hope to have it up
> again by the end of this month.
What does it do?
----------------------------
See response to "what is the MMS gateway?"
-------------------------------------
> 2. Everyone can send an MMS. Only those who have been successful in
> setting up e-mail from their mobile devices are able to send e-mail. I'm
> EXTREMELY technically knowledgeable in this area and even I have been
> unsuccessful in setting up my phone to work to work with my e-mail server.
> 3. Pricing for MMS is predictable - and now affordable. Without a plan,
it
> typically cost a user about $.50 per picture. A Fido messaging plan for
> example however allows 1000 MMS and 2500 SMS messages for $20/month. So
> worst case a user spends $.50 to send a picture - at least he knows what
the
> cost is. E-mail however uses standard data rates. Without a data plan
these
> rates are about $.03/kbyte. So to send a 300K picture via e-mail with no
> plan, it will cost the user about $9 - versus $.50 per MMS. Of course
there
> are now e-mail plans available. Again how many users have e-mail plans
> though.
I did not realize MMS may be shared per use. How common is its use?
Are people used to spending 50c when they want to do something, or is
it more used in special circumstances? I'm not sure there is
sufficient "payoff" in this proposal to warrant people spending money
to contribute.
----------------------------
I'm not sure what your first statement was intended to say.
I'm in no position to talk about market acceptance of technologies such as
MMS. Broadly speaking, MMS is a lucrative opportunity for carriers.
Verizon reports carrying 250 million MMS/quarter and most recently noted a
30% quarter-quarter increase. Are people used to paying for MMS? I don't
know. If they're used to paying for SMS I suppose they're used to paying
(more) for MMS. As I said, one of the benefits of MMS is that it has a
comprehensible billing play - ala SMS. (Whether there is fair value to that
plan is of course debatable).
Like I say, all carriers offer messaging plans that offer reduced rates on
SMS/MMS. In that sense, the recent kerfuffle over $.15 receive SMS seems
more like a tempest in a teapot - since I messaging plans are relatively
cheap.
------------------------------------------------
Alexandre Quessy
Maybe you should be interested in using the rawmaterials application I
am developping at SAT. It is a download manager that is hooked to the
RSS feeds that lists all the submitted contents. This Python
application downloads all the files that match your channels and
criterias. You will be able to control it using OSC messages. This
will definitely be possible with Pure Data. A first version should
before the end of August.
That might simplify things for what you want to do.
Cheers,
a
2008/8/11 Jim Udall <jim....@quickmobile.com>:
>
> Responses embedded
>
> Jim
>
> -----Original Message-----
> From: muse3-p...@googlegroups.com
> [mailto:muse3-p...@googlegroups.com] On Behalf Of b
> Sent: Saturday, August 09, 2008 10:49 AM
> To: MUSE3 Platform
> Subject: Re: Overview of approaches to use MUSE to enable receiving cell
> phone images in installation
>
>
> Hello Jim,
>
> Thanks for taking the time to answer my questions. Inline are a few
> follow-up comments.
>
>> In terms of your own application, the platform would receive the MMS then
>> deliver it to your application (presumably running on your computer) via
> an
>> HTTP POST. If you're at all familiar with web programming this is a very
>> simple interface methodology. So "No -you don't need a PC with a
> connected
>> cell phone". You just need a PC with an internet connection.
>
> What is the "platform"? Muse running on a particular cell phone? To
> clarify:
>
> -----------------------
>
> MUSE platform is a hosted service available at developers.mobilemuse.ca that
> offers a number of features and capabilities. Those services and features
> are intended to be useful in deploying network base mobile applications.
> Some services are low level and offered as SOAP or REST accessed web
> services. Others are packaged as components or applications - configurable
> and useable via any web browser. Among the low level services offered by
> the platform or bi-directional text messaging and bi-directional MMS
> messaging. How SMS or MMS is actually implemented is of no concern to you
> as a developer. This is important since especially for SMS, there are a
> variety of means to affect services. You as the developer need not concern
> yourself with how these services are affected. Indeed, that is one of the
> goals of the platform.
> --------------------------------------
>
> 1. Cell user uses MMS to send image to another cell phone (the one
> used for the installation)
> 2. That second cell phone is running a MUSE application which routes
> incoming MMS images to HTTP post on a web-server running on the
> installation computer (or somewhere else).
> 3. The installation computer receives the images via post and which is
> then opened in Pure Data.
>
> So if the cell is not connected to the PC, then there needs to be a
> cell phone that acts as a router for all the incoming MMS messages. Is
> this what the "mms gateway" does?
>
> -----------------------------------------------
> The MMS Gateway is a subsystem of the MUSE platform.
> ---------------------------------
>
> Could a cell be configured to dump all incoming MMS images to flash
> memory, which would be mounted via USB mass storage so the files could
> be easily transferred to the installation computer?
> -------------------------------------------
> Understand that this is not something of even remote interest to MUSE
> platform. However, if you want to explore this possibility yourself...
> Nokia phones (like all cell phones), can be configured to automatically
> accept incoming MMS messages (ala SMS). Nokia software I believe allows you
> to connect your phone to a PC and copy over the MMS messages. You would
> then have to parse these MMS messages (exercise left to the reader), to
> extract the pertinent content.
> ---------------------------------------------
>
>
> I agree the email and java solutions seem more awkward.
>
>> 1. The MMS implementation in the MUSE platform is based on a GSM modem.
> As
>> a result, the thruput is VERY slow. You'll be lucky to get 2 MMS per
> minute
>> out of it. MUSE is an experimental research platform so I don't apologize
>> for this limitation. I believe MMS has a role to play in user generated
>> content from the mobile space, but the reality is that carriers in Canada
>> are just not positioning any technology to do this on a large scale. It
> is
>> my opinion that this will evolve (as it already has done so in other
>> countries).
>
> What is the bit-rate of the gsm modem? I'm expecting images at
> 1280x1024 at the absolute maximum. The proposal is more about many
> people sending images, not the same person sending many images.
>
> ----------------------------------------------------
> Bit rates are pretty much irrelevant. MMS is exchanges using standard
> EVDO/1X/GPRS/EDGE packet data networks. There are of course raw bit rates
> for all these technologies, but over wireless, any discussion of bit rates
> is meaningless because of issues such as air performance and cell capacity.
> Not to mention the cost of establishing and tearing down packet data calls.
> IN some sense, on some phones, the sender has more control over the size of
> MMS messages. Nokia for example allows you to configure MMS to send
> small/medium or large pictures. This is not a universal statement.
>
> And BTW, a notable exception to the ubiquity of MMS is the iPhone. It does
> NOT support sending or receiving of MMS.
>
> -----------------------------------------
>
>> 2. Currently our MMS gateway is inoperative (effective the beginning of
>> this week). It's a long story why that is the case. I hope to have it up
>> again by the end of this month.
>
> What does it do?
> ----------------------------
>
> See response to "what is the MMS gateway?"
> -------------------------------------
>> 2. Everyone can send an MMS. Only those who have been successful in
>> setting up e-mail from their mobile devices are able to send e-mail. I'm
>> EXTREMELY technically knowledgeable in this area and even I have been
>> unsuccessful in setting up my phone to work to work with my e-mail server.
>> 3. Pricing for MMS is predictable - and now affordable. Without a plan,
> it
>> typically cost a user about $.50 per picture. A Fido messaging plan for
>> example however allows 1000 MMS and 2500 SMS messages for $20/month. So
>> worst case a user spends $.50 to send a picture - at least he knows what
> the
>> cost is. E-mail however uses standard data rates. Without a data plan
> these
>> rates are about $.03/kbyte. So to send a 300K picture via e-mail with no
>> plan, it will cost the user about $9 - versus $.50 per MMS. Of course
> there
>> are now e-mail plans available. Again how many users have e-mail plans
>> though.
>
> I did not realize MMS may be shared per use. How common is its use?
> Are people used to spending 50c when they want to do something, or is
> it more used in special circumstances? I'm not sure there is
> sufficient "payoff" in this proposal to warrant people spending money
> to contribute.
> ----------------------------
> I'm not sure what your first statement was intended to say.
>
> I'm in no position to talk about market acceptance of technologies such as
> MMS. Broadly speaking, MMS is a lucrative opportunity for carriers.
> Verizon reports carrying 250 million MMS/quarter and most recently noted a
> 30% quarter-quarter increase. Are people used to paying for MMS? I don't
> know. If they're used to paying for SMS I suppose they're used to paying
> (more) for MMS. As I said, one of the benefits of MMS is that it has a
> comprehensible billing play - ala SMS. (Whether there is fair value to that
> plan is of course debatable).
>
> Like I say, all carriers offer messaging plans that offer reduced rates on
> SMS/MMS. In that sense, the recent kerfuffle over $.15 receive SMS seems
> more like a tempest in a teapot - since I messaging plans are relatively
> cheap.
>
> ------------------------------------------------
--
Alexandre Quessy
http://alexandre.quessy.net/
--
Alexandre Quessy
http://alexandre.quessy.net/
Roland Tanglao
I have read the entire thread and your requirements are too vague to
give a definitive answer. But you are technical person (impressive
software developer CV by the way) so I am sure this is just because
it's the beginning of the project.
Your requirements seem to be:
1. Allow as many contributors (who are these people, what kind of
devices do they have?) to send photos via their mobile phone
2. Receive images (what resolution?) & transfer to PC
Here are some ways you can accomplish what I think you want:
I. Without platform
1. photos from a phone tagged w/specific tag e.g."bbaxtercoolart" ->
flickr (via MMS, email, programs like ShoZu, AirMe, etc) -> RSS feed
of tag -> PC-> RSS Parser gets image at lo-res (240x180) from RSS
Feed
2. photos from a phone tagged w/specific tag -> flickr (via MMS,
email, program like ShoZu, AirMe) -> PC -> use flickr REST API to ge
whatever resolution you want (e.g 640x480 up to full resolution)
II. With MUSE 3 platform using SIFT
1. create a channel e.g. one called "bbaxtercoolart" using SIFT
2. channel aggregates photos with tag "bbaxtercoolart" on flickr as
well as photos sent from mobile devices via email and MMS
3. use the images from the channel's RSS feed
I bet Pure Data being open source already has both Flickr API and RSS
plugins available since retrieving flickr photos and parsing RSS is a
favourite "Hello World" kind of program for people these days.
And of course you can also possibly using SAT's VJ Muse 3 App as
Alexandre suggested.
Finally MMS in Canada is really bad as Jim pointed out so all the
limitations apply (e.g. 300K limit, it works as the British say in a
"dodgy" kind of fashion and nobody I know uses MMS although millions
of young people in the USA and elsewhere use it to send really lo-res
photos to their buddies!). But that's not a problem if the
contributors are outside of Canada (but then non Americans and non
Canadians may not be able to or want to MMS to a Canadian number)
Hope that helps, sounds like further requirement details are required
possibly followed by a face to face or IM
meeting. If you are on Skype, you can skype IM me (rtanglao) anytime.
Cheers!
...Roland
b
The technical vagueness of my needs is a result of two issues. First
the idea is fresh and not complete, really an add on to another
project. Second the idea is perhaps too simple for muse or at least
not aligned with the purpose of MUSE.
To take a stab at the central purpose of Muse:
A platform for the integration of cellular phone content (sending and
receiving) and web applications.
If I have this right or wrong please let me know, but all the keywords
going on in this discussion lead me to believe this is the case.
A more detailed description on the project:
* MAM is a responsive site-specific system that actively explores its
context (using a PTZ camera) to form a portrait of the space around
it. This portrait is not an entirely literal representation, but based
on the unique interaction of the systems AI and the stimulus from the
environment. The system generates a kind of dream from its collected
content. If you want more info let me know and I can pass on a more
precise description.
* As MAM is about its immediate visual context, the more constrained
the subject matter (the regularity of the context) the more compelling
the subject matter. This may be problematic when it comes to
contributions from cell phones, as they may not be sufficiently
constrained.
* Ideally contributed images would be constrained to the immediate
physical area around the installation, in order to provide a theme. Is
there a way to filter images based on the physical location of the
cell tower being used? Even then I suppose the area would be very
wide.
Seems all the suggested approaches are based on a website as an
interface between installation and the cell phones. As an installation
artist I'm more interested in a direct relation between the
installation and the cell phone, rather than depending on a gateway
website.
Who are the users?
People who live/work/play in the immediate physical environment in
which the installation happens, perhaps the SAG and Bear Creek Park in
Surrey.
People who have camera phones and are comfortable using them to share
content.
The resolution of the images is of little consequence, as low as
100x75 is possible, 640x480 a nice middle.
I really appreciate all the comments and efforts.
The current project is based on images, but the mechanism could work
in many different types of media.
I can think of three ways cells can contribute content: Voice (leave a
message at a number), MMS, SMS. Any of these could be an approach to
this project, but would obviously change it significantly. Dealing
with SMS sounds like it would be most easy, but the most complex when
it comes to my system itself.
The purpose of me writing this post was to start a discussion about my
idea to feel out its potential, possibility in the context of the muse
commissions.
It seems less and less feasible for MAM+Muse to work for myself. That
being said I'm open to collaboration so if anyone finds these ideas
interesting maybe there is potential there.
An off-topic question: Is there a FLOSS flikr? That is a copyleft,
community driven site that uses only FLOSS and is run by its
community, rather than a corporation.
Thanks again,
B. Bogart
Roland Tanglao
Thanks for giving us more details.
I think discussing MAM would be a great session at New Forms Mobile
Day on September 21 (talk to Megan Cole and Jean Hebert about this) as
well as MobileCampVancouver (http://barcamp.pbwiki.com/
MobileCampVancouver2, FREE) on September 6.
To answer your questions:
1. There is no Floss flickr. Start one! I'd love to help with that
2. "Ideally contributed images would be constrained to the immediate
there a way to filter images based on the physical location of the
cell tower being used? Even then I suppose the area would be very
wide."
from around the MAM installation (BIG assumption: people who are
around the MAM installation have phones that can create geotagged
content). The problem here is that
few Canadians have cameraphones that record the GPS coordinates in
the
photos and other media so unless you can give your MAM collaborators
phones that do this and teach them
it's not going to happen. The iPhone 3G, Nokia N95, Nokia N82, etc
does this but how many MAM collaborators
will have such higher end phones?
3. "Seems all the suggested approaches are based on a website as an
artist I'm more interested in a direct relation between the
installation and the cell phone, rather than depending on a gateway
website. "
e.g flickr, youtube, etc
but in my opinion you gotta go where the people
are and flickr and youtube are where the people are
for example flickr has over 5000 photos uploaded
per minute!
Photos or media of any type directly to a PC from a mobile device is
certainly possible (e.g. using bluetooth
or email)
but very geeky and not very easy to use (but if your collaborators are
geeks
then of course that's not a problem)
Anyways, I don't have time to collaborate on this with you but am very
intrigued.
Love to discuss this further from my perspective of creating and
sharing mobile content since 2004
with you over drinks at Chill Winston or coffee at WorkSpace if you
are ever in
Gastown. Ping me via email to rol...@raincitystudios.com or SMS to 604
729 7924
and we can arrange to discuss this!
...Roland