The project requires two or more cell phones in a dark container. One of the phones will take a picture with its flash.
The other phones will take a picture without flash by holding the equivalent of their shutters open long enough, and
with the right timing, to use the flashing phone for illumination.

Then each phone in the container will take a turn at taking a picture with a flash, and all other phones will use the
flash from that currently flashing phone to get a picture in the same way.

When all phones have flashed, the images will be transferred to to PC for processing.

My questions:

1) Will acquiring the images in this way require a custom phone application in each phone?

2) Which phone, and which phone OS, is best suited for this task?

3) If a custom app is required, what IDE should be used? The project is on a low budget, so an IDE licensing cost is a
factor.

--
To respond to me directly remove sj. from the my email address's domain name. This is a spam jammer.

On 1/17/2022 7:01 PM, Artist wrote:
> The project requires two or more cell phones in a dark container. One of the
> phones will take a picture with its flash. The other phones will take a picture
> without flash by holding the equivalent of their shutters open long enough, and
> with the right timing, to use the flashing phone for illumination.
>
> Then each phone in the container will take a turn at taking a picture with a
> flash, and all other phones will use the flash from that currently flashing
> phone to get a picture in the same way.

For what purpose? SfM?

> When all phones have flashed, the images will be transferred to to PC for
> processing.
>
> My questions:
>
> 1) Will acquiring the images in this way require a custom phone application in
> each phone?

Likely. Consider how you would trigger each phone -- let alone tell
it whether it is its turn to use its flash.

Does the camera API let you hold the shutter "open", indefinitely?
Or, does it require you to pick from one of N exposure times?
Or, is it all automagic?

How do you have the phones talk to each other? Or, do you run the
entire process open-loop? (in which case, how do you tell each
phone "you are #N"? "Of M"?)

Do you synchronized to GPS time to eliminate the need to pass
timing information between phones?

> 2) Which phone, and which phone OS, is best suited for this task?
>
> 3) If a custom app is required, what IDE should be used? The project is on a
> low budget, so an IDE licensing cost is a factor.

On 1/17/2022 7:53 PM, Don Y wrote:
> On 1/17/2022 7:01 PM, Artist wrote:
>> The project requires two or more cell phones in a dark container. One of the phones will take a picture with its
>> flash. The other phones will take a picture without flash by holding the equivalent of their shutters open long
>> enough, and with the right timing, to use the flashing phone for illumination.
>>
>> Then each phone in the container will take a turn at taking a picture with a flash, and all other phones will use the
>> flash from that currently flashing phone to get a picture in the same way.
>
> For what purpose?  SfM?
>
>> When all phones have flashed, the images will be transferred to to PC for processing.
>>
>> My questions:
>>
>> 1) Will acquiring the images in this way require a custom phone application in each phone?
>
> Likely.  Consider how you would trigger each phone -- let alone tell
> it whether it is its turn to use its flash.
>
> Does the camera API let you hold the shutter "open", indefinitely?
> Or, does it require you to pick from one of N exposure times?
> Or, is it all automagic?
>
> How do you have the phones talk to each other?  Or, do you run the
> entire process open-loop?  (in which case, how do you tell each
> phone "you are #N"?  "Of M"?)
>
> Do you synchronized to GPS time to eliminate the need to pass
> timing information between phones?
>
>> 2) Which phone, and which phone OS, is best suited for this task?
>>
>> 3) If a custom app is required, what IDE should be used? The project is on a low budget, so an IDE licensing cost is a
>> factor.
>

I am not at liberty to disclose the purpose. This a Phase 1 proof of concept SBIR project. So I seek an arrangement to
accomplish it with the least effort, and expense. Having all phones controlled by one of the phones, or an external
laptop, will be acceptable.

I expect communication would be by Bluetooth. USB is also acceptable. Whichever requires the least effort. Synchronizing
with GPS time is an excellent idea if it is not practical to do it by Bluetooth, or USB. Communication has to be too
way, because the images from all phones have to aggregated into the master phone, or mastering PC, for processing.

It looks to me now that Android would be the best OS for this, and the IDE should be Android Studio. Unknown by me now
is whether exposure time is controllable in its camera API. Possible scenarios are:

1) Command shutters open on all camera's other than the flashing camera. Take the picture with flashing camera. Then
close all the shutters.

2) On all the cameras that do not flash, set an exposure time lone enough to assure the flash from the flashing camera
is captured, and no longer than that. Trigger the non flashing cameras, then trigger the flashing camera.

--
To respond to me directly remove sj. from the my email address's domain name. This is a spam jammer.

On 1/17/2022 9:39 PM, Artist wrote:
> On 1/17/2022 7:53 PM, Don Y wrote:
>> On 1/17/2022 7:01 PM, Artist wrote:
>>> The project requires two or more cell phones in a dark container. One of the
>>> phones will take a picture with its flash. The other phones will take a
>>> picture without flash by holding the equivalent of their shutters open long
>>> enough, and with the right timing, to use the flashing phone for illumination.
>>>
>>> Then each phone in the container will take a turn at taking a picture with a
>>> flash, and all other phones will use the flash from that currently flashing
>>> phone to get a picture in the same way.
>>
>> For what purpose? SfM?
>>
>>> When all phones have flashed, the images will be transferred to to PC for
>>> processing.
>>>
>>> My questions:
>>>
>>> 1) Will acquiring the images in this way require a custom phone application
>>> in each phone?
>>
>> Likely. Consider how you would trigger each phone -- let alone tell
>> it whether it is its turn to use its flash.
>>
>> Does the camera API let you hold the shutter "open", indefinitely?
>> Or, does it require you to pick from one of N exposure times?
>> Or, is it all automagic?
>>
>> How do you have the phones talk to each other? Or, do you run the
>> entire process open-loop? (in which case, how do you tell each
>> phone "you are #N"? "Of M"?)
>>
>> Do you synchronized to GPS time to eliminate the need to pass
>> timing information between phones?
>>
>>> 2) Which phone, and which phone OS, is best suited for this task?
>>>
>>> 3) If a custom app is required, what IDE should be used? The project is on a
>>> low budget, so an IDE licensing cost is a factor.
>
> I am not at liberty to disclose the purpose. This a Phase 1 proof of concept
> SBIR project. So I seek an arrangement to accomplish it with the least effort,
> and expense. Having all phones controlled by one of the phones, or an external
> laptop, will be acceptable.

How they "talk" will have a significant impact on their physical deployment
as there are practical limits to all comms methods -- especially wired.
(wireless has its own can of worms)

> I expect communication would be by Bluetooth. USB is also acceptable. Whichever
> requires the least effort. Synchronizing with GPS time is an excellent idea if
> it is not practical to do it by Bluetooth, or USB. Communication has to be too
> way, because the images from all phones have to aggregated into the master
> phone, or mastering PC, for processing.

You need to know how tightly you *must* synchronize before you can sort
out how you *can* synchronize -- which, in turn, has impact on how
they "talk" to each other (or to a "master")

> It looks to me now that Android would be the best OS for this, and the IDE
> should be Android Studio. Unknown by me now is whether exposure time is
> controllable in its camera API. Possible scenarios are:
>
> 1) Command shutters open on all camera's other than the flashing camera. Take
> the picture with flashing camera. Then close all the shutters.
>
> 2) On all the cameras that do not flash, set an exposure time lone enough to
> assure the flash from the flashing camera is captured, and no longer than that.
> Trigger the non flashing cameras, then trigger the flashing camera.

You should be able to see how communications costs/latencies will directly
impact either of these approaches!

Sort out your requirements before you start looking for an implementation
(or, define your requirements based on the constraints imposed *by* a
chosen implementation!)

On Mon, 17 Jan 2022 22:23:12 -0700, Don Y
<blockedofcourse@foo.invalid> wrote:

>On 1/17/2022 9:39 PM, Artist wrote:
>> On 1/17/2022 7:53 PM, Don Y wrote:
>>> On 1/17/2022 7:01 PM, Artist wrote:
>>>> The project requires two or more cell phones in a dark container. One of the
>>>> phones will take a picture with its flash. The other phones will take a
>>>> picture without flash by holding the equivalent of their shutters open long
>>>> enough, and with the right timing, to use the flashing phone for illumination.
>>>>
>>>> Then each phone in the container will take a turn at taking a picture with a
>>>> flash, and all other phones will use the flash from that currently flashing
>>>> phone to get a picture in the same way.
>>>
>>> For what purpose? SfM?
>>>
>>>> When all phones have flashed, the images will be transferred to to PC for
>>>> processing.
>>>>
>>>> My questions:
>>>>
>>>> 1) Will acquiring the images in this way require a custom phone application
>>>> in each phone?
>>>
>>> Likely. Consider how you would trigger each phone -- let alone tell
>>> it whether it is its turn to use its flash.
>>>
>>> Does the camera API let you hold the shutter "open", indefinitely?
>>> Or, does it require you to pick from one of N exposure times?
>>> Or, is it all automagic?
>>>
>>> How do you have the phones talk to each other? Or, do you run the
>>> entire process open-loop? (in which case, how do you tell each
>>> phone "you are #N"? "Of M"?)
>>>
>>> Do you synchronized to GPS time to eliminate the need to pass
>>> timing information between phones?
>>>
>>>> 2) Which phone, and which phone OS, is best suited for this task?
>>>>
>>>> 3) If a custom app is required, what IDE should be used? The project is on a
>>>> low budget, so an IDE licensing cost is a factor.
>>
>> I am not at liberty to disclose the purpose. This a Phase 1 proof of concept
>> SBIR project. So I seek an arrangement to accomplish it with the least effort,
>> and expense. Having all phones controlled by one of the phones, or an external
>> laptop, will be acceptable.
>
>How they "talk" will have a significant impact on their physical deployment
>as there are practical limits to all comms methods -- especially wired.
>(wireless has its own can of worms)
>
>> I expect communication would be by Bluetooth. USB is also acceptable. Whichever
>> requires the least effort. Synchronizing with GPS time is an excellent idea if
>> it is not practical to do it by Bluetooth, or USB. Communication has to be too
>> way, because the images from all phones have to aggregated into the master
>> phone, or mastering PC, for processing.
>
>You need to know how tightly you *must* synchronize before you can sort
>out how you *can* synchronize -- which, in turn, has impact on how
>they "talk" to each other (or to a "master")
>
>> It looks to me now that Android would be the best OS for this, and the IDE
>> should be Android Studio. Unknown by me now is whether exposure time is
>> controllable in its camera API. Possible scenarios are:
>>
>> 1) Command shutters open on all camera's other than the flashing camera. Take
>> the picture with flashing camera. Then close all the shutters.
>>
>> 2) On all the cameras that do not flash, set an exposure time lone enough to
>> assure the flash from the flashing camera is captured, and no longer than that.
>> Trigger the non flashing cameras, then trigger the flashing camera.
>
>You should be able to see how communications costs/latencies will directly
>impact either of these approaches!
>
>Sort out your requirements before you start looking for an implementation
>(or, define your requirements based on the constraints imposed *by* a
>chosen implementation!)

Since you will need to power these cameras/phones, you could use USB
for both communications nd power.

Or, USB for power and WiFi or BT for comms. BT isn't all that great
for long time connections in my experience but maybe WiFi isn't either
? Or USB ? They will all need some kind of Watch-Dog in my opinion.

IDEs for Android phone apps are free. Androind Studio I think it is
called comes to mind.

I think this might be kind of a difficult app to do so you would have
to find someone that is really good is my guess. At my work, we can't
even seem to get someone to do a simple app like a data monitor to a
Bluetooth dongle. Might try one of those app developer web sites.

We have done SBIRs before. At leaset you are at phase 1. Good luck !
boB

On 1/18/2022 2:29 AM, boB wrote:
> On Mon, 17 Jan 2022 22:23:12 -0700, Don Y

>> Sort out your requirements before you start looking for an implementation
>> (or, define your requirements based on the constraints imposed *by* a
>> chosen implementation!)
>
> Since you will need to power these cameras/phones, you could use USB
> for both communications nd power.

The OP hasn't mentioned anything about how the units are placed:
"... in a dark container". That could be a *shoebox* -- or, a
shipping container! In the latter case, cable lengths can be
on the order of 10 or more feet -- esp if *each* unit is tethered
to a "master" (of some sort).

> Or, USB for power and WiFi or BT for comms. BT isn't all that great
> for long time connections in my experience but maybe WiFi isn't either
> ? Or USB ? They will all need some kind of Watch-Dog in my opinion.

There are Tx/Rx latencies in all of these technologies. Can the OP
control when a particular message "hits the wire"? ("air"?) Or,
how soon after Rx the message is available to the application?

And, are these times *bounded* in any way?

Is there anything that insists only a *single* flash be generated
per exposure interval? Why not *two*?

> IDEs for Android phone apps are free. Androind Studio I think it is
> called comes to mind.
>
> I think this might be kind of a difficult app to do so you would have
> to find someone that is really good is my guess. At my work, we can't
> even seem to get someone to do a simple app like a data monitor to a
> Bluetooth dongle. Might try one of those app developer web sites.

First nail down your requirements so you can see if the developer is
capable of meeting them. Someone who isn't aware of the timeliness
constraints (and hasn't enough experience to know what the phone/OS
guarantees in that regard will be) is likely going to waste a lot
of time ($$) and produce dubious results ("Well, it *kinda* works...")

I think apps, like web pages, have devolved into "frameworks with
annotation" -- in the spirit of letting *anyone* be a coder (you
don't need to understand what you're doing, just tie these things
together and *hope*!)

> We have done SBIRs before. At leaset you are at phase 1. Good luck !
> boB
>
>

On 1/18/2022 1:59 AM, Don Y wrote:
> On 1/18/2022 2:29 AM, boB wrote:
>> On Mon, 17 Jan 2022 22:23:12 -0700, Don Y
>
>>> Sort out your requirements before you start looking for an implementation
>>> (or, define your requirements based on the constraints imposed *by* a
>>> chosen implementation!)
>>
>> Since you will need to power these cameras/phones, you could use USB
>> for both communications nd power.
>
> The OP hasn't mentioned anything about how the units are placed:
> "... in a dark container".  That could be a *shoebox* -- or, a
> shipping container!  In the latter case, cable lengths can be
> on the order of 10 or more feet -- esp if *each* unit is tethered
> to a "master" (of some sort).
>
>> Or, USB for power and WiFi or BT for comms.  BT isn't all that great
>> for long time connections in my experience but maybe WiFi isn't either
>> ?  Or USB ?   They will all need some kind of Watch-Dog in my opinion.
>
> There are Tx/Rx latencies in all of these technologies.  Can the OP
> control when a particular message "hits the wire"?  ("air"?)  Or,
> how soon after Rx the message is available to the application?
>
> And, are these times *bounded* in any way?
>
> Is there anything that insists only a *single* flash be generated
> per exposure interval?  Why not *two*?
>
>> IDEs for Android phone apps are free.  Androind Studio I think it is
>> called comes to mind.
>>
>> I think this might be kind of a difficult app to do so you would have
>> to find someone that is really good is my guess.  At my work, we can't
>> even seem to get someone to do a simple app like a data monitor to a
>> Bluetooth dongle.  Might try one of those app developer web sites.
>
> First nail down your requirements so you can see if the developer is
> capable of meeting them.  Someone who isn't aware of the timeliness
> constraints (and hasn't enough experience to know what the phone/OS
> guarantees in that regard will be) is likely going to waste a lot
> of time ($$) and produce dubious results ("Well, it *kinda* works...")
>
> I think  apps, like web pages, have devolved into "frameworks with
> annotation" -- in the spirit of letting *anyone* be a coder (you
> don't need to understand what you're doing, just tie these things
> together and *hope*!)
>
>> We have done SBIRs before.  At leaset you are at phase 1.  Good luck !
>> boB
>>
>>
>
The government's SBIR proposal request requires the photos be taken by cameras in cell phones. The philosophy is that it
be done with readily available off the shelf devices, of which cell phones are ubiquitous. The request also requires
that they be shot by the means I described.

The cell phones are to be distributed within a roughly 3' diameter dome, where they will be mounted on its inner
surface. It is a given that the interior of this dome will be in total darkness, and that the cell phones will be
stationary. I judge it safe to count on it being so for this project.

I cannot get into what image processing will be done with the collected images.

I am looking at the usefulness of this now:
https://macrodroid.com/

--
To respond to me directly remove sj. from the my email address's domain name. This is a spam jammer.