Launch with image path?

[simonbjork]

Is there a way to launch fSpy with an image path? It would be a pretty useful feature as it would allow you to start fspy from a separate application with the image path set automatically.

Something like:
fspy -i /path/to/image.jpg

[david-cattermole]

Hello @simonbjork and @stuffmatic,

This sounds like a fairly easy feature to implement (especially since v1.0.3 includes a command line interface already).

@stuffmatic
Would you mind if I fork and add this feature and merge it back in? (I also want this feature myself).

David

[simonbjork]

Wow, that sounds great @david-cattermole! I have a Nuke importer from fspy done, would love to write an exporter as well :).

I wonder, if you add the argument to launch with a filepath, do you think you can save that filepath in the project somehow as well, so we could query it from python like the other project variables?

[stuffmatic]

I'm aiming to release a new fSpy version soon(ish), with some improvements and fixes. I'll look into adding support for launching with an image path. While I really appreciate your offer @david-cattermole, it's probably easier if I have a look at it.

I have a Nuke importer from fspy done, would love to write an exporter as well :).

Cool! Is this something you're planning to release? @simonbjork

I wonder, if you add the argument to launch with a filepath, do you think you can save that filepath in the project somehow as well, so we could query it from python like the other project variables?

Do you have a specific use case in mind @simonbjork? I'm not yet convinced that storing the entire file path is a good idea, since there's so guarantee it remains valid. If you need to access the image data, its embedded in the project file.

[simonbjork]

@stuffmatic : Yes, I plan to release it, it's pretty much done and working. It would be nice to release it as a kit though with both the exporter and importer. Basically it would work like this:

exporter: Select a read node in nuke. Run the exporter and fspy will launch with the image path and load the image. If possible it could also send the filmback data as well.

importer: Run the importer and browse to the fspy project file. Import the camera and setup a basic scene. Also it would link in the image so we would get a nice preview. I also plan to do this for Modo, and then we can setup an image backround from the original file.

Both modo and nuke use linked media so we can't store any actual pixel data. So if I were to use the data that is in the project file, I would need to save a new file which isn't ideal. I'm fine if the path is no longer valid, that's something for importer scripts to handle.

[david-cattermole]

I'm aiming to release a new fSpy version soon(ish), with some improvements and fixes. I'll look into adding support for launching with an image path. While I really appreciate your offer @david-cattermole, it's probably easier if I have a look at it.

Sure @stuffmatic, I understand.

For reference, I'd probably use fSpy as an executable in my mmSolver project:
david-cattermole/mayaMatchMoveSolver#121

Unfortunately I cannot combine fSpy code with mmSolver, due to license conflicts (GPL vs LGPL).

I am also looking to write an importer/exporter, but for Maya. I wouldn't mind having the original file path inside the project file (or the exported JSON file).

For Maya integration my workflow would be:

1. In Maya, select a camera with an image plane or pop-up a GUI prompting for an image file.

2. Maya Python script then launches fSpy with image file path (as a separate process).

3. In fSpy, use fSpy to calculate the camera matrix.

4. In fSpy, user saves the project file, or exports a Camera Parameter JSON file.

5. In Maya, the user selects the camera, opens tool and chooses the fSpy project file path.

6. In Maya, we parse the project/camera parameters JSON file and convert it to a transform matrix and set it on the selected camera.

The intent is for fSpy to be used quickly with minimal effort.

At step 2, it would be good if a fSpy flag could automatically save the project file to a specified file path as well. This way the user just needs to press "CTRL + S" and we can detect the process has exited.

The above workflow would be integrated into my mmSolver project, however if you're interested, I could probably contribute by adding an export format for Maya (as .mel)?

The .mel file would create a new camera with the expected values. If an image file path was also given then the tool could create an image plane with the original file path. It's possible to be invalid, but it's better than nothing and in the common use-case I'd expect the file to exist.

[stuffmatic]

I've just published 1.1.0-beta.1 which supports passing a path to an image or project when launching the app like so:

[fSpy executable] open [path to image or project]

I'll have to think some more about if storing image paths in project files and passing a preferred project path on launch can be done in some reasonable way.

Both modo and nuke use linked media so we can't store any actual pixel data. So if I were to use the data that is in the project file, I would need to save a new file which isn't ideal.

@simonbjork This is how the Blender imported works, i.e it extracts the image data from the project file, saves it to a temp file and loads that file.

[simonbjork]

Thanks a lot @stuffmatic, I'll give it a try later today!

Regarding the filepaths: I do think it would be really useful to save the original filepath. It would be hidden in the fpsy file so you would only find it if you really were looking for it. Also, this issue is not specific to fpsy, it's for pretty much every importer. In a importer script you just look if the file exists and if it does you import it.

Having a separate file (that is also stored locally) would not be great at least in vfx. Files need to be stored on the server and in the original format etc. So in the current version a user would first need to import the fspy project then import the footage. So with the filepath we could get this down to 1 step instead of 2.

[simonbjork]

@stuffmatic : I just did some tests and I can't get it to work. I tried with:

fSpy.exe open D:\room.jpg
fSpy.exe open D:/room.jpg
fSpy.exe --open D:/room.jpg

But none seems to work, it just stops at the menu saying Drop an image or project here. I also tried opening a project file via the open argument and that didn't work as well.

[stuffmatic]

@simonbjork I've only done testing on my mac so far and it seems to work for valid files. However, I did just realize that no error message is shown when passing an invalid path. Will look into this.

To rule out the possibility that special characters are causing issues, could you try quoting the path, "D:\room.jpg", or referencing a file in the same directory as the executable, room.jpg?

[simonbjork]

I tested both, but unfortunately still no luck.

I get this in the terminal, don't know if it's related:
(electron) The default value of app.allowRendererProcessReuse is deprecated, it is currently "false". It will change to be "true" in Electron 9. For more information please check https://github.com/electron/electron/issues/18397

[stuffmatic]

@simonbjork I just published a new beta version with improved error reporting if the path passed at launch cannot be opened. It would be great if you could try again and report what you're seeing in the terminal.

[simonbjork]

@stuffmatic: It seems to work now. First it didn't and now it does, really strange. Not sure what happend. Anyway, this is going to be great.

[simonbjork]

Do you have a list of supported image formats?

[stuffmatic]

@simonbjork Good to hear that it works! Let me know if you see any interesting error messages. fSpy is based on Electron, so it can handle any image formats that chromium can handle. I don't have a list at the moment, but any format you can expect a modern web browser to handle.

[simonbjork]

Hm, I just tried again and now it doesn't work. Exact same command.

It's strange, when it does work fspy starts in a small window, when it doesn't work it starts in full-screen. No error messages. It feels random.

[stuffmatic]

@simonbjork Are you sure you're running the same fSpy version for all tests? The version number is shown in the top right corner of the start screen

[simonbjork]

Yes, I have double checked.

…

------------------------------- Simon Björk Compositor/TD +46 (0)70-2859503 www.bjorkvisuals.com Den tis 14 apr. 2020 kl 15:37 skrev Stuffmatic <[email protected]>:

@simonbjork <https://github.com/simonbjork> Are you sure you're running the same fSpy version for all tests? The version number is shown in the top right corner of the start screen [image: Screenshot 2020-04-14 at 15 36 32] <https://user-images.githubusercontent.com/2444852/79231091-d47d4e80-7e65-11ea-90e9-3c6f7ab5bb2c.png> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUCQOIV6LBPHAHIFDO7FR3RMRRKTANCNFSM4GTYDSUA> .

[stuffmatic]

If you pass an invalid image path, like any random string, on purpose, do you get an error message? @simonbjork

[simonbjork]

It's random. 1. Send it to fspy via nuke tool (same as the gif): No image, starts in full screen. 2. Try via command line: No image, starts in full screen. 3. Command line and random string: No error, starts in full screen. 4. Mess around. 5. Suddenly command line works, it gives error for random strings, it imports image, starts in smaller window, nuke tool works. 6. It stops working. 7. Repeat.

…

------------------------------- Simon Björk Compositor/TD +46 (0)70-2859503 www.bjorkvisuals.com Den tis 14 apr. 2020 kl 15:49 skrev Stuffmatic <[email protected]>:

If you pass an invalid image path, like any random string, on purpose, do you get an error message? @simonbjork <https://github.com/simonbjork> — You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub <#11 (comment)>, or unsubscribe <https://github.com/notifications/unsubscribe-auth/ACUCQOO456XZ4OJCPQRUM3TRMRSXXANCNFSM4GTYDSUA> .

[simonbjork]

I did a few more tests and it stopped working again.

However, I then cleared the ../AppData/Roaming/fSpy directory, and now it seems to work. I think :).

[stuffmatic]

@simonbjork Let me know if you see the issue again

[MitchellKehn]

Hey! I was working on basically the same tool as @simonbjork -a Nuke importer/exporter for fSpy - when I found this thread.

I've tested out the fSpy open "filename" command in 1.1.0-beta3 and 1.1.0-beta2 and found the same issue where in fullscreen/maximised mode the image is loaded from the path I give it, and in non-maximised/floating mode it loads fine.

For me the behavior seems pretty clear though, not random: fSpy saves the window state from the last time, and then returns to that. i.e. if it was maximised it opens maximised, if it was floating when last closed, it opens up as a floating window. Didn't seem random or anything. Clearing the AppData directory didn't seem to help it though.

Also, might be worth adding the "open" command to the help message you get with fSpy -h

[MitchellKehn]

@simonbjork I had a go at forking the repo to fix the intermittent loading behavior, and a couple other changes. I've not done any electron development before, so it's all pretty minor.

There's some Windows binaries for it here if you wanted to test it out. (note that I had to change the command from fSpy open <filename> to fSpy --open <filename>)

Pull request for this one is here.