Camera application violate DCF standard

RESOLVED FIXED

Status

Firefox OS
Gaia
P3
normal
RESOLVED FIXED
6 years ago
6 years ago

People

(Reporter: hub, Assigned: daleharvey)

Tracking

unspecified
x86_64
Linux

Firefox Tracking Flags

(blocking-basecamp:+)

Details

(Whiteboard: QARegressExclude)

Attachments

(1 attachment)

(Reporter)

Description

6 years ago
(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

6 years ago
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]
(Reporter)

Comment 5

6 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

6 years ago
Hub - discussed at length in other places.  Applications will decided where things should be stored.
(Reporter)

Comment 7

6 years ago
*sigh*
Component: General → Gaia
Whiteboard: [blocked-on-input Dale Harvey]
(Assignee)

Updated

6 years ago
Assignee: nobody → dale
(Assignee)

Comment 8

6 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)
(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

6 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

6 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

6 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

6 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
(Assignee)

Updated

6 years ago
Depends on: 798304

Updated

6 years ago
blocking-basecamp: ? → +
Priority: -- → P2
(Assignee)

Comment 14

6 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

6 years ago
Priority: P2 → --

Updated

6 years ago
Priority: -- → P3
(Assignee)

Comment 15

6 years ago
Created attachment 676386 [details]
Store media files captured by camera with DCF compliant paths
Attachment #676386 - Flags: review?(dflanagan)
Attachment #676386 - Flags: feedback?(hub)
(Reporter)

Comment 16

6 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

6 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 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

6 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
Last Resolved: 6 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.

Comment 22

6 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.