Open image from absolute path name

In my desktop app (for Mac and Windows), I need to be able to load images (for display.newImage) from anywhere in the user’s file system. I am using the tiny file dialogs plug-in and other ways to allow the user to locate the image they want, which gives me a full pathname for the image file. The problem is, display.newImage only allows relative pathnames, (relative to system.DocumentsDirectory being the only logical choice here).

So, right now I have to do a nasty and platform-dependent partial workaround to compute a path relative to system.DocumentsDirectory (which by the way is not the normal Documents folder but the hidden app support folder…). To try to make it general, right now I’m running up to the root then back down to the desired file, like:

…/…/…/…/…/…/…/…/path/down/from/root/to/finally/file.png

but this won’t work across different drives or networks, is a mess to test, is platform-dependent, etc.

Does anybody know a better way? Or any chance I can convince Corona to add a baseDir option for images (and sounds) for use on desktop only that essentially disables the baseDir and treats the filename like a normal full or relative path (just like io.open would)?

Hi.

While not exactly “a better way”, I could probably add something like this (only on desktop, I think?) to a function I’ve recently added and will soon be testing in my Bytemap plugin. That would go something like this:

local data = bytemap.loadTexture{ filename = MY\_FILENAME, baseDir = false } -- false = absolute local image = display.newImage(data.filename, data.baseDir, data.width, data.height) -- could probably now do data:Deallocate(), this not being Android, but that also needs testing :P -- do whatever with data data:releaseSelf()

A bit indirect, but should be familiar if you’ve ever played with canvases.

EDIT : Better choices than false welcome, of course.

@starcrunch - Interesting.  That would make previewing non-sandbox images easier for desktop apps like @dparker7 is talking about.

I’d be interested in using something like that.

Of course, once a user selected an image for some kind of ‘use’ the only correct way to use it is to move it local by making a copy, but this would save a lot of temporary copies.

Right now I achieve previewing remote images by copying them to a temporary location then destroying the copies when done.  ick!

Okay, assuming I didn’t botch anything, this should now be present in the aforementioned plugin, callable as follows:

local data = bytemap.loadTexture{ filename = MY\_FILENAME, is\_absolute = true } -- MY\_FILENAME = "/Users/User/ME/MyAwesomeImage.jpg", "C:/Users/ME/MySweetPhoto.png", etc. -- rest as in previous example

(For the moment the docs still say this function is a WIP, since I think I need to update the mobile binaries to even include it. Also, this should go live soon and ought to make it possible to eliminate some user-side workarounds needed on Android, so that’s still in progress.)

Hi.

While not exactly “a better way”, I could probably add something like this (only on desktop, I think?) to a function I’ve recently added and will soon be testing in my Bytemap plugin. That would go something like this:

local data = bytemap.loadTexture{ filename = MY\_FILENAME, baseDir = false } -- false = absolute local image = display.newImage(data.filename, data.baseDir, data.width, data.height) -- could probably now do data:Deallocate(), this not being Android, but that also needs testing :P -- do whatever with data data:releaseSelf()

A bit indirect, but should be familiar if you’ve ever played with canvases.

EDIT : Better choices than false welcome, of course.

@starcrunch - Interesting.  That would make previewing non-sandbox images easier for desktop apps like @dparker7 is talking about.

I’d be interested in using something like that.

Of course, once a user selected an image for some kind of ‘use’ the only correct way to use it is to move it local by making a copy, but this would save a lot of temporary copies.

Right now I achieve previewing remote images by copying them to a temporary location then destroying the copies when done.  ick!

Okay, assuming I didn’t botch anything, this should now be present in the aforementioned plugin, callable as follows:

local data = bytemap.loadTexture{ filename = MY\_FILENAME, is\_absolute = true } -- MY\_FILENAME = "/Users/User/ME/MyAwesomeImage.jpg", "C:/Users/ME/MySweetPhoto.png", etc. -- rest as in previous example

(For the moment the docs still say this function is a WIP, since I think I need to update the mobile binaries to even include it. Also, this should go live soon and ought to make it possible to eliminate some user-side workarounds needed on Android, so that’s still in progress.)