Closed Bug 794564 Opened 12 years ago Closed 12 years ago

Camera application violate DCF standard

Categories

(Firefox OS Graveyard :: Gaia, defect, P3)

x86_64
Linux
defect

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.
blocking-basecamp: --- → ?
Any thoughts here, Mike?
I think it's a Media Storage issue, not a camera issue.
The pathname is defined in the camera app; adding dale.
Should we file this as a gaia issue instead?
Whiteboard: [blocked-on-input Dale Harvey]
IMHO, implementing DCF should be part of the WebAPI for camera. And then up to gaia to call the right API.
Hub - discussed at length in other places.  Applications will decided where things should be stored.
*sigh*
Component: General → Gaia
Whiteboard: [blocked-on-input Dale Harvey]
Assignee: nobody → dale
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)
(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.
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.
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)
(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.
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
Depends on: 798304
blocking-basecamp: ? → +
Priority: -- → P2
Do we want to use a single store for videos and pictures? 

    DCIM/100MZFFO/IMG_00001.jpg
    DCIM/100MZFFO/VID_00002.3gp

for example
Priority: P2 → --
Priority: -- → P3
Attachment #676386 - Flags: review?(dflanagan)
Attachment #676386 - Flags: feedback?(hub)
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+
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 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+
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
iphoto detecting card upon mount, but not showing any photos - bug 812240. possibly related to this bug.
Tested on Unagi version 20130103070201, and it appears to follow the DCF standard now.
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.

Attachment

General

Created:
Updated:
Size: