Feature request (again): Picture/Camera import during run

I’ve added the ability to have a background picture to my version of the Harmony program. The idea being that one can load a picture and then “sketch” it by drawing on top. This would be great if one could do it with a picture dynamically chosen from the photo library, or taken by the camera.

This is something that @Mark has requested.

The main issue with the implementation is that it brings up a modal UI, so any picker would need to have an asynchronous callback for when the image is picked. I don’t particularly like this requirement, I’d also like to have a blocking call (that pauses Lua execution). This will require a large architectural change to Codea, moving the Lua execution out of the rendering thread.

I could potentially add the asynchronous UI first (as is the case with http.request) and then look at a blocking UI later.

How about this. Start with an interface to the Photo Library rather than the Camera (since one could always take a picture with the camera and then get it from the library afterwards). Make it so that we can get a list of albums and pictures in those albums, or so that there is a special Codea album that we can read (and write?) to. This wouldn’t need blocking or async calls. Then the UI should give us access to the names (if available), thumbnails, and full images. Then we could write a picture-picker in-app where the thumbnails are displayed (easy with a mesh) and the user can pick one.

Also makes it possible to have a slideshow, or a slowly changing background, or lots of things.

Well that should be possible now, the Photo Library is accessible through the sprite picker. So user photos can be added to your Documents or Dropbox sprite packs. The sprites can then be listed with the spriteList() function and used to create your own image picker.

On iOS, developers aren’t trusted with users’ private photos. iOS requires use of its modal picker UI for all photo album selections. I agree with Apple’s policy in this regard (developer’s can’t be trusted), but it does mean we can’t implement generalised photo picking in the viewer without an asynchronous callback (or re-architecting the renderer, which would be a great update).

Ah, I hadn’t clicked as to how the Dropbox/Documents feature worked and the spriteList() function in particular. I’ll give that a whirl.

I see the point about Apple’s UI requirement and amongst their restrictions I’d say it’s one that I’d be willing to live with. So how about a mixture of these systems. Codea invokes the picker and that simply copies pictures from the Photo Library into the Documents sprite pack. At the moment, I have to do it through a bit of a complicated system within the editor so all I want is a way to invoke this in-program. Then my program can access this list how it likes. Probably when the photo picker is done it should send a signal (or call a callback) to the program to say “New photos in the sprite pack”. That seems minimally intrusive.

While I’m at it, is there a way to save an image (created in Codea) to an image somewhere?

\Read the documentation, stupid\

Okay, found saveImage. Forget I mentioned it!

iPad gone the way of all iPads - to the kids - so I’ll work some more on this later. But it looks promising.

Happy my daughter is just 16 months… For a little more time I should be safe frome kid stoling the iPad!

How things are going? Are you fighting with the read/saveImage api?

I think that the documents/ dropbox integration is good enough for development but can’t be really used as filesystem rep for a running app because the only way to handle the contents of this folders is through the editor or doing some trick and using an external file manager from pc/mac.

Moreover the dropbox/documents folder have no direct access even from the editor: they require to write in the editor something like sprite() or readImage(), then tap on the helper that appears in the brackets and from the picker copying or synching images.

It would be great to have a faster access and (I’m dreaming now, I know), maybe even some api like the ones that allows to handle recording, callable directly from the apps. I mean, at least the dropbox sync!

Ah, @Andrew_Stacey, take care that, even if not documented, the api allows to use also subfolders if you want!

Well, ideals aside, I now have a picture browser and can import background images to the Harmony code and export the result back again.

Can you get to documents outside of Codea? It’s dandy that I can put things there, but I don’t see how to get at them from any other app. What I’m looking for is a way to import and export images. It doesn’t have to be the modal UI, but it does have to be accessible to exchange images between users.

I want a way to trigger the camera, and hopefully manipulate the image, ultimate goal being things like time-lapse recording, or motion detection (and subsequent recording), and if I’m really good getting enough computer vision going on to put a mustache on everyone looking at the camera, BECAUSE. :slight_smile:

Picture browser now in my library code.

Mark, I think you can save them to the Dropbox folder. I’ll give it a go later (up to now, I’ve been working with the Documents sprite pack but only for convenience sake).

Bortels, Yes that would be fun. But the current functionality is more than I thought we had so I’m going to see what’s possible with that and hopefully get some ideas as to what I’d like from doing that.

What about allowing saves directly to the photo library through the saveimage function? Many applications write images there without user interaction. SaveImage(“PhotoLibary:key”, image) and readImage(“PhotoLibrary;key”) would solve about 90% of my issue. The only thing remaining would be a way to get a set of valid keys using SpriteList(“PhotoLibrary”).

Any reason this is off the table?

@Mark saveImage(“PhotoLibrary:key”) is definitely possible. readImage and spriteList are not, as the user must use the modal iOS photo picker to select a photo. Apps are not allowed to read the contents of the photo library at all, the OS allows an app to present the system picker, which will eventually give the app a single image.

I want to put the modal picker in, but initially it will require an asynchronous API, which is a design I’m not too keen on.

In the meantime, I have two requests:

  1. A sprite pack manager in the Organiser part of Codea so that I can import/export pictures and organise my sprite pack before I run a program. Essentially pretty much what I can do by tapping on the sprite keyword but without having to load a program.
  2. An in-program test to see if Dropbox is available so I can load that if it is available and drop back to Documents if not.

Number 1 makes a lot of sense.

I’m a bit unclear on what you mean by 2. Wouldn’t spriteList(“Dropbox”) tell you what is available in Dropbox?

Can it tell the difference between an empty Dropbox and an unlinked Dropbox?

Ah I see what you mean. Because you don’t know whether you can save to Dropbox.

As I wrote in http://twolivesleft.com/Codea/Talk/discussion/1265/taking-a-picture-modification-to-codea-runtime#Item_11 I’ve added this to the runtime. With pickImage(“Documents:Foo”) to take a picture and save it to documents. It stops the runtime.

And I also added sprite(“Camera:Back”) to render the camera stream into an app. But it still needs some polishing, but I think it would take Codea to a new level to be able to manipulate camera streams.

Thinking about this again. Why not treat picturechooser as you do keyboard? Looking at how picturechooser works in several art applications (say, something as simple as Chop Suey) it appears as a float over menu.

Deal with it using a showPictureChooser() and hidePictureChooser() and an optional pictureChooser() function that mimics the keyboard() function.

function pictureChooser(picture)
     If picture ~= nil then
          myImage = picture.image
          myImageName = picture.name