Closed
Bug 794564
Opened 12 years ago
Closed 12 years ago
Camera application violate DCF standard
Categories
(Firefox OS Graveyard :: Gaia, defect, P3)
Tracking
(blocking-basecamp:+)
RESOLVED
FIXED
blocking-basecamp | + |
People
(Reporter: hub, Assigned: daleharvey)
References
Details
(Whiteboard: QARegressExclude)
Attachments
(1 file)
(I don't have an Otoro phone, so the camera does not work on my dev phone - but I tested this by checking somebody else's Otoro phone). The camera app violate the DCF standard by dumping all the picture in the /DCIM directory and by not using a compliant naming scheme: this will make the phone no able to be recognized by PC application like iPhoto to download the pictures. Here is the wikipedia entry about DCF http://en.wikipedia.org/wiki/Design_rule_for_Camera_File_system Also I had already warned that the demo with the files uploaded when installing Gaia was breaking it. FWIW, Android breaks it differently, we don't want to be like those guys.
Updated•12 years ago
|
blocking-basecamp: --- → ?
Comment 1•12 years ago
|
||
Any thoughts here, Mike?
Comment 2•12 years ago
|
||
I think it's a Media Storage issue, not a camera issue.
Comment 3•12 years ago
|
||
The pathname is defined in the camera app; adding dale.
Comment 4•12 years ago
|
||
Should we file this as a gaia issue instead?
Whiteboard: [blocked-on-input Dale Harvey]
Reporter | ||
Comment 5•12 years ago
|
||
IMHO, implementing DCF should be part of the WebAPI for camera. And then up to gaia to call the right API.
Comment 6•12 years ago
|
||
Hub - discussed at length in other places. Applications will decided where things should be stored.
Reporter | ||
Comment 7•12 years ago
|
||
*sigh*
Updated•12 years ago
|
Component: General → Gaia
Whiteboard: [blocked-on-input Dale Harvey]
Assignee | ||
Updated•12 years ago
|
Assignee: nobody → dale
Assignee | ||
Comment 8•12 years ago
|
||
This is a tad problematic as there can potentially be a lot of photos and we need to enumerate all of them before we know what filename we can use every time the camera starts, but I can implement it in Gaia How does DCIM/100MZB2G/DCS_00001.jpg sound? (the wiki examples and text seem to contradict themselves)
Comment 9•12 years ago
|
||
(In reply to dale@arandomurl.com from comment #8) > This is a tad problematic as there can potentially be a lot of photos and we > need to enumerate all of them before we know what filename we can use every > time the camera starts, but I can implement it in Gaia Interesting thing: most cameras (that I've owned :) don't restart the numbering sequence when you remove all of the images from the camera--so they cache the last-used value somewhere. You may want to consider that. > How does DCIM/100MZB2G/DCS_00001.jpg sound? (the wiki examples and text seem > to contradict themselves) I think we should prefer '100MZFFO' or something Firefox-OS-y over '100MZB2G'. Also, 'DCS_00001.jpg" has one too many zeros.
Assignee | ||
Comment 10•12 years ago
|
||
Well the problem with caching the value (I have noticed that as well) is that when the cache gets wiped, I guess if we randomly generate the 100 in the 100MZFFO part and cache that as well we at least only have a 1 in 999 chance that we start overwriting the users photos, but I would prefer no chance, I will see how fast I can enumerate a large filled SD card and report back if this will be problematic.
Assignee | ||
Comment 11•12 years ago
|
||
The other problem with caching is people writing in from the side, but I guess part of DCS is too avoid that problem, so doing a scan iff the cached value isnt available seems like a good solution. I will work on it (for Camera + Video)
Reporter | ||
Comment 12•12 years ago
|
||
(In reply to dale@arandomurl.com from comment #10) > Well the problem with caching the value (I have noticed that as well) is > that when the cache gets wiped, I guess if we randomly generate the 100 in > the 100MZFFO part and cache that as well we at least only have a 1 in 999 > chance that we start overwriting the users photos, but I would prefer no > chance, I will see how fast I can enumerate a large filled SD card and > report back if this will be problematic. You cache the value. If the value isn't cached, you determine it by finding the folder with the highest number (only the first 3 digits counts, the suffix shouldn't matter) and create a newer with one extra more. And start at number 0001. BTW what is that "DCS_"? just use "IMG_", no need to be cryptic.
Assignee | ||
Comment 13•12 years ago
|
||
That has to be done by scanning all the files anyway, but it does sound like saner logic and I just seen my camera call things DCS and was mentioned in the wikipedia article as well, IMG_ and VID_ work better for me Thanks
Updated•12 years ago
|
blocking-basecamp: ? → +
Priority: -- → P2
Assignee | ||
Comment 14•12 years ago
|
||
Do we want to use a single store for videos and pictures? DCIM/100MZFFO/IMG_00001.jpg DCIM/100MZFFO/VID_00002.3gp for example
Updated•12 years ago
|
Priority: P2 → --
Updated•12 years ago
|
Priority: -- → P3
Assignee | ||
Comment 15•12 years ago
|
||
Attachment #676386 -
Flags: review?(dflanagan)
Attachment #676386 -
Flags: feedback?(hub)
Reporter | ||
Comment 16•12 years ago
|
||
Comment on attachment 676386 [details]
Store media files captured by camera with DCF compliant paths
Looks right to me.
Albeit, I can't test it since I haven't been allowed to use my Unagi phone as a development phone and the SGS2 camera still isn't supported.
Attachment #676386 -
Flags: feedback?(hub) → feedback+
Reporter | ||
Comment 17•12 years ago
|
||
Comment on attachment 676386 [details]
Store media files captured by camera with DCF compliant paths
Cancelling feedback. The first directory should have number 100, not number 001 like with the current patch.
Attachment #676386 -
Flags: feedback+ → feedback-
Comment 18•12 years ago
|
||
Comment on attachment 676386 [details]
Store media files captured by camera with DCF compliant paths
r+, but see the comments on github.
As far as I can tell Hub's feedback comment is mistaken (or you've updated the patch since he made it).
Attachment #676386 -
Flags: review?(dflanagan) → review+
Assignee | ||
Comment 19•12 years ago
|
||
heh sorry I had updated my commit based on hubs feedback merged in: https://github.com/mozilla-b2g/gaia/commit/47fd823b703f65b8d46fd9c4348f50cbe68fdfb6
Status: NEW → RESOLVED
Closed: 12 years ago
Resolution: --- → FIXED
Comment 20•12 years ago
|
||
iphoto detecting card upon mount, but not showing any photos - bug 812240. possibly related to this bug.
Comment 21•11 years ago
|
||
Tested on Unagi version 20130103070201, and it appears to follow the DCF standard now.
Comment 22•11 years ago
|
||
Tested on Unagi version 20130112070202, and it appears to continue to follow the DCF standard now.
Whiteboard: QARegressExclude
You need to log in
before you can comment on or make changes to this bug.
Description
•