feature request: auto save and log parameters (with file names) to txt

[rayset]

autosaving the result after a run it's a killer feature and should be quite simple to do.

log the parameters, with the output file name (just for completed runs) would make this a must have. many neural users simply lose their settings, having an autolog would be amazing.

I will look myselft in to those feature too, but I'm a bit busy this month.

[cameronleger]

Thank you for trying the program and the request.

There might not actually be anything to do here. You'll notice that each time you start the process a new item is added to the list in the Output tab. Here you can access all of the previous runs, load those settings, and see the iteration images.

Well, all of those images and parameters are saved into the OS' temporary directory, which is almost certainly /tmp considering that most Neural-Style users are on a Linux/GNU OS. A new directory is used for each 'session' (read: program start), however the previous ones do remain in the other directories until cleaned by the OS, and that's usually on reboot and possibly over a long period of time. With some user effort you could find previous runs and their parameters in there.

Although, I guess what you're interested in is persistent storage for these items, or some of them at least. I considered that but opted for the temporary solution because of file sizes. Running a lot of different 'trials' results in a ton of images, and I'm using the PNG output to avoid JPG compression, so the file sizes are higher.

I can see a few necessary and optional changes here:

• Better/Different default unique names for unnamed runs. Right now it's the current time in milliseconds. I've considered a combination of the style and content image names.
• Using the provided output name with a unique ID to generate the temporary files so that items in the history list are more easily identifiable.
• Allowing the user to change where the temporary iterations are stored, so that all of this information could be persistent.
• Assuming the above change has been made, showing all previous history in the Output tab or perhaps even a new tab specifically for history.
• Saving the parameters file next to the output image every time an output is 'Saved' by the user. Completed, see commit 7b517a2

After reading your request again, perhaps the last item there is more of what you're getting at, and is one of the easier things to implement. The difficulty is defining a 'completed run.' I frequently stop the process early (300 - 600 iterations) when the outputs are sometimes better then.

[rayset]

I'll look into it. I think I'll end up saving a log of all jsons or something like that.

side note: I fear the output tab displays not the final image but the last iteration befere it.

so if iteration is set to 1000 I think it shows iteration 900. I don't know if I broke something (but I have touched very little), but I don't see the last file on the right table and the preview is exactly the same as the last one listed. some times it even skips 900 and has only 800.

this is more evident if image update is high, say 300. Take a look in to it, tomorrow I will reinstall from zero and see if the error persists.

[cameronleger]

Check out the commit I just pushed, it does what I mentioned as the last bullet item: the Save Image button also saves a style file with the image. This way, you'll always have a way to recreate the images you've saved.

Also, you're probably right about the default mode of the Output tab showing the n-1 image. I hacked together a solution for not displaying files that are still being written to, and it's probable that's the cause. I think it's also evident at the very beginning because the history will update but there's no image in the view. Note that selecting an iteration from the history does not suffer from this, although that's just a workaround to the problem.

[rayset]

I've just tested the save feature and it's really good. I don't have the time for today to check the other news,it seems promising.

I'll let you know if I get some ideas about the last image issue. The most annoying thing is having no way to see the 1000-th image, since it doesn't ever appear in the history, even after you switch to another image generation...the ''lag'' of 1 image is a good solution, it only needs a rule to update the list after the exit code of neural style with the final one (that has a different name I think, without the iteration number). or when you press start again...I think you don't detect at all the completed run for now.

I'm also not sure what does the save button actually save... I fear it's not the actual last image but the last in the history in this case too. Will test tomorrow, if I manage to do something (I hate septembers :( ) I'll shoot a more serious pull request.

[cameronleger]

OK Great. It was largely that change.

I didn't realize it might not appear in the history. The 'lag' should only happen if the latest file is relatively smaller than the last image, but I think that's happening more frequently than it should. It's also possible that it always happen and the workaround is borked.

The Save Image button will save whatever it is you're looking at. With no selections in the history panel, it's probably the 2nd-to-last iteration as you've discovered. If you select a top level Style in the history panel, it's basically the same result except that you could be looking at a previously generated run. If you select an image under the Style tree, it will save that image you've selected.

[cameronleger]

Check out the recent commit which fixes the last image issue. Now, checking for new images gives the latest image a brief period of time to be written to before returning the results, and I can confirm that the latest images are now showing up in the view and history panel. It does introduce a very slight GUI delay during the image write period, however it's negligible considering everything will be running slower while neural-style is running anyway.

[rayset]

yes, I can confirm that it works.

I noticed that the order of images (style and content) seems to be randomic, what's their sorting? can't check the source atm, but for huge folders like mines it can be tricky.

imho having fixed that bug and added those couple of features, this could be a nice 1.1 release :)

I'd aslo suggest you to upload the jar in the repo, maven can be a no-no for new users, as most neural artists come with no programming background at all, even more if they are looking for a gui.

Sooner or later I'll try to implement cnnmrf and neural doodle as we said on reddit, making it customizable would be great, but maybe a too tedious task.

[rayset]

just to thow another future idea, for anyone with the time: the possibility to add multiple works in a batch. basically adding a button ''add to queue'' that copies the command generated to a file (maybe some ui element to display the number of works in the queue), and then having the start button execute all lines in the file.

[cameronleger]

Excellent. I believe the images are sorted seemingly at random, but it's at least consistent. In previous commits I had a table instead of lists and that allowed sorting on the filename, but when I switched to the more concise lists I lost that. Perhaps sorting the files by name before handing them to the lists will work for now, as I cannot think of another way of sorting them that would be beneficial.

We'll have to discuss the Maven idea further. I've only experience with private Maven repositories, but I didn't quite get what you're suggesting. I don't think it's about making sure that this repo is in Maven, because as you said that would be unnecessarily daunting. Do you mean having the release JAR included in this code repo? If so, I do release versions with the GitHub releases, so you can download a ZIP including the JAR and libraries along with a script to start it correctly.

I have also toyed with the batch idea for a while. Considering the average user's setup will be minimal/untinkered, this GUI will take up some of their precious vRAM - especially so with lots of images - so I see it as more of a rapid prototyping tool where you can copy the command when you like the output and run that in a terminal for more resources.

My setup involves PCI Passthrough and with a few modifications I've been able to run this GUI on my iGPU while having the NVIDIA GPU only processing the neural-style command for maximum resource usage. Then, I play with a few outputs until I find what I like, copy the commands for each, and put them in a shell script to run overnight. The shell script approach could even work for most users, although I agree that that's probably asking more from most of them than they're comfortable with.

Maybe we both realise that this project stradles the line between power users and those with minimal computer/programming knowledge. It will be a balancing act for sure, but I would put in the effort for a batch or queue type feature.

[rayset]

Yeah I was suggesting having the jar downloadable from the repo. for people with no IDE and that haven't ever used ''mvn package'' it can be messy. I noticed the release tab tho, that's more user friendly for sure.

as for the vram I barely see any difference, but atm I have a 1070 so maybe on something like a 960 it could be a problem. What's the usage on your machine? for me it's about 40mb of vram if nvidia-smi is telling the truth.

[cameronleger]

It is probably around there as well with my 970 if I remember correctly, but much more was taken up by general Xorg processes - nearly 800MB which I guess is attributable to the 4K resolution and many workspaces. Now that Xorg is running on the iGPU, nvidia-smi shows no processes utilizing the GPU or vRAM, so neural-style has more to play with.

It's also worse in CPU mode because the RAM is used instead. I noticed up to 2GB from the GUI alone after scrolling through the images a few times, but I do not have control over JavaFX's memory usage so that's just a drawback for now.

[rayset]

I saw you updated the files using lists instead of arrays (I assume for the order?). Now it won't compile for me:

Error:(383, 72) java: incompatible types: java.lang.Object[] cannot be converted to com.cameronleger.neuralstylegui.model.NeuralImage[]

I'd also put 1_8 in neural-style-gui.iml:

it doesn't work with my maven or intellij else way, since rel 1.0.0 I think...but could be a problem on my end. if it compiles just fine for you, could you upload the latest jar? thanks

[cameronleger]

My bad, I didn't include the other changed file. I could've kept them in arrays, however at that point I was converting them from array -> list -> array so I just cleaned it up a little in the process.

In any case, I figured this was enough for v1.1.0, so you can also grab it from the Releases tab.

[rayset]

Yep, I tried converting them to arrays in a second line too, but on windows it gave me some exceptions (maybe for the nvidia vram bar). glad it works now :)

[cameronleger]

For the other item in this discussion, I've created another issue for it and will consider this closed.