App-set JPEG compression

[GoogleCodeExporter]

What steps will reproduce the problem?
1. Take a picture
2. Share picture with a contact

What is the expected output? What do you see instead?
Glass uploads a massive 5MP photo with high quality, but for any app that's 
trying to deliver near real-time results, speed is much more important than 
photo quality.

What version of the product are you using? On what operating system?
Latest OTA update as of 7/9/13.

Please provide any additional information below.
This may be fixed by any of the following:
a) Compressing the picture according to a Contact's setting. For example, a 
contact may have a 'quality' key, where the app developer that inserted the 
contact is able to determine what quality is acceptable for their app.
b) Modifying compression according to the user's current upload speed
c) Allowing the user to change their camera's resolution in Settings

Original issue reported on code.google.com by nextvent...@gmail.com on 9 Jul 2013 at 6:14

[GoogleCodeExporter]

Original comment by mimm...@google.com on 9 Jul 2013 at 6:15

• Added labels: Component-Mirror-API, Priority-Low

[GoogleCodeExporter]

This is relevant for my project, what would be useful is if a contact can 
configure the image resolution (not the jpeg compression) that is returned by 
the service.  It appears that the main delay is glass -> google when on mobile 
data.

Original comment by e133tc1pher@gmail.com on 17 Jul 2013 at 3:07

[GoogleCodeExporter]

We experienced 10-60 second uploads on 4G networks at a really high profile 
event. We had to abandon our Glass app altogether because the wait times were 
just too long to be useful.

Ideally we'd have control over both the image resolution and the compression 
level, so we could get this time down even when the networks are bogged down.

Original comment by myglass...@gmail.com on 22 Jul 2013 at 1:57

[GoogleCodeExporter]

Can you expand at all on the use cases that benefit from lower resolution 
images?  

I ask because real time Glassware will be best solved with the GDK, but I do 
see how this could be useful for the Mirror API. Use cases help us prioritize 
our efforts.

Original comment by mimm...@google.com on 22 Jul 2013 at 9:06

• Changed state: Accepted
• Added labels: log-7437352

[GoogleCodeExporter]

Sure. We're running A.I. algorithms on images and responding with relevant 
information based on what we recognize. In order to do this, we need to 
transfer the image to our own servers, process it, then send back a response.

It's not possible for Glass to do this kind of processing on-board, so it seems 
like this is a Mirror API issue, correct?.

Original comment by nextvent...@gmail.com on 23 Jul 2013 at 12:33

[GoogleCodeExporter]

The Mirror API is always going to require network round trips. Scaling the 
image on Glass before sending it may save you some time, but 50% of 30 seconds 
is still 15 seconds. 

For real time, GDK is probably going to be a better solution. It will allow you 
to run code on Glass and avoid the network round trip. It's not ready yet, but 
you can get stated now by developing Android apps and side-loading the APK on 
to Glass with adb. GDK will provide APIs that allow for easier integration into 
Glass, but the general development model won't change drastically. 

So, I suppose, my question is: is GDK the solution to your issue, or are the 
other benefits of the Mirror API something you're still hoping for out of your 
Glassware? 

Original comment by mimm...@google.com on 23 Jul 2013 at 12:56

[GoogleCodeExporter]

I guess some combination of GDK and the Mirror API would be ideal—that is, we 
could use UX tricks to reduce the apparent wait time while we compress the 
image and upload it.

In most tests, though, I've found that the time to upload is usually 5-10 
seconds. Cutting that to 2-4 seconds is doable and would make a world of 
difference.

As to your question, the GDK alone is most definitely not the solution to our 
issue, as we need a collection of high-powered servers to do the processing in 
near real-time.

Original comment by nextvent...@gmail.com on 23 Jul 2013 at 1:18

[GoogleCodeExporter]

Understood. Thanks for circling back. :)

Original comment by mimm...@google.com on 23 Jul 2013 at 1:46

[GoogleCodeExporter]

We've decided not to pursue this one in the near future so I'm adjusting the 
priority listed here to reflect that decision. 

If you have a use case that absolutely requires this functionality, please add 
it here. We can always reshuffle priorities.

Original comment by mimm...@google.com on 1 Aug 2013 at 12:10

• Added labels: Priority-Later
• Removed labels: Priority-Low