Thanks to the efforts of developer friends who are trying to give us the new version as soon as possible if we are not killed by Corona, I personally enjoy working with Sa at all but in some places I am still really confused because of the years of work with photoshop UX and UI, for example working with layers in photoshop.
I'm really used to the way the layers are arranged and operated in it, I know that in the SA it is possible to do everything I do (and maybe this method is even better than) in Photoshop, but I have problem with that,Is it possible that in the next version, users like me will be able to use the layering method exactly like Photoshop, and those who are comfortable with the current method will continue in the same way?
You need to be a member of Studio Artist to add comments!
Replies
Studio Artist is not Photoshop. If we made it work just like PhotoShop, what's the point. Just use PhotoShop and be done with it.
The whole point is that it's different.
...
On a different topic, i do appreciate all of the various suggestions you have emailed me, and i have them all documented in a folder here.
I was meaning to email you about this, but for time efficiency i will just ask you here in this thread.
If you had to only choose 4 of the various 'feature suggestions' you have sent me, what would those 4 features be?
I'm assuming 'decorative' paint strokes (for lack of a better term in my mind at the moment) would be one of them.
Please don't say 'make it more like photoshop' as one of the 4. If anything, we're moving more and more away from a 'photoshop' paradigm as we move into the future here. My viewpoint of the 'photoshop paradigm' is really all about manual visual page layout of vectors and images, and endlessly putting off actual design decisions by using 40 or more live effect layers (to do something you could do in a single layer with compositing in Studio Artist)
Wow, that means you are now letting me to give four of my requests?!
I've always seen SA like Superhero and over the years, had hundreds of requests and you have always responded kindly and as You know I am not graphic artist and would like to have these:
1-Vector/Bitmap Draw floral ornaments in auto and manual mode With the guidance of mouse even better than this: ___1/___2.
2-Auto and manual editor segmentation for making better mosaic
and Topology Maintained Structure Encoding and Generating Surface Crack Patterns.
3-Fast and optimized auto and manual vector/text/bitmap objects Decoration without overlapping, We give SA some text/vectors/transparent png objects like this and program put them together and for text art and micrography.
In my college (I am master of restoration), we often find ancient pieces of broken object that we have to hardly classify, and by putting the pieces and shapes, colors and images together correctly, we end up with a comprehensive Now, if there is the same ability for graphic work in the software (SA had some of these abilities to make this) By googling it called "Solving Jigsaw puzzles" and said It is designed to assist cultural heritage operators in reconstructing broken pictorial artifacts from their fragments. These undergo feature extraction and feature based indexing, so that any fragment can be the key to queries about color distribution, shape and texture. Query results are listed in order of similarity, which helps the user to locate fragments likely to be near the key fragment in the original picture.
4-Import Processing or javascript files and run them for making generative procedural art.
And if any of the above can not be done in any way, I like you to consider one of the following :
*Html text instead simple text with supporting Right to left languages.
*Pattern Recognition for for human portrait drawing
*generating stencil for laser cutters with connected Islands by bridges.
*Importing shaders
*create patterns for robots
*Create automatic abstract regions of color
*some algorithm for 3d CNC
*Procedural modeling
*Synthesis of Filigrees for Digital Fabrication
*algorithm like Intel Open Image Denoise for make large images
Thank you
In general these are great suggestion. So thank you.
However, # 4 is not going to happen. Ever.
If you want to use Processing, by all means go ahead. But don't expect it to hook up to Studio Artist.
Javascript (yuch). Best to be avoided at all costs unless absolutely necessary. My opinion.
We have a long term project here in association with the Haiku Tech Center to do something kind of like Processing for artists (but our own take on it), but totally Python based. Python is great.
Now that you might expect that alternative platform to hook up to a future version of Studio Artist at some point in the future. Assuming that particular project bears fruit.
Everything else is a great suggestion.
So shaders and SA
Our upcoming (next year people) SA V6 architecture has an abstraction layer built on top of the various (all different) platform GPU architectures. With this in place, you can expect a big push with shaders in SA. Without this abstraction layer, it's an exercise in futility.
Apple is killing off OpenGL and moving exclusively to Metal. Yes, Big Sur still supports an old OpenGL implementation, but if we supported that, we would be in exactly the same situation we were with the quicktime api in a year or 2.
Windows is moving to Direct 3D 11.
Other platforms are moving to Vulcan.
We support all of these via our abstraction layer. Which let's us program them all with a single interface. Hiding the intensely gory internal details.
Increased intelligence in general (visual and other)
A number of your suggestions kind of fall into this general category. A lot of effort behind the scenes has been going on here to address this. That research is ongoing, and you can expect it to show up all over the place next year and beyond.
Ornamental Drawing
That's what i was referring to when i said 'decorative' drawing above.
And our plans are to start incorporating some new features to address this kind of thing.
All of this is extremely interesting to me.
Some very cool examples posted above :)
I have asked for some sort of C++ API in the past so that I might work with OpenFrameworks and SA.
In any case, python is great, and I would love to both have some scripting in SA, and play with this framework your involved with.
I am making an effort to use SA more, and make it a regular part of my creative work flow, scripting would probably make that easier for me.
Is OpenFrameworks even going to survive all of the changes currently happening in the compute world? My understanding is that it's totally OpenGL based, and that is a dead letter box at this point.
I have the same question about Cinder as well (which always seemed more interesting to me in some respects than OpenFrameworks).
Just to clarify your thinking in my mind re: scripting.
What kinds of things do you want to script in SA that you can't just do in a PASeq?
Good questions. I don't know how they plan to address openGL.
I suspect with some middleware that will bridge openGL to Vulcan and Metal. But that's a guess.
I guess what I would find interesting is if I could pass a texture to SA, and tell SA to run PASeq or other process, and have a texture returned to me. (single frame).
Or for multi-frame I guess pass a file pointer, and get a new file pointer once complete.
My usage would likely be interactive installation based. Where user images are taken and processed and added to an evolving art piece.
This may include multi-projector video mapping the environment, maybe live updating a web gallery, sending images to users via email, and/or more.
I would likely use the OF to create control software to integrate control of the cameras and capture (canon DSLR API), web interfacing, projection mapping, SA processing, and more.
We're interesting in adding an external command protocol in SA V6. It's in our V6 design spec.
So this is a mechanism that could be used to talk to Studio Artist and ask it to run various commands.
Those external commands could include opening an external image as a source, doing various things in Studio Artist, saving the canvas to an external image, etc.
So you could use this mechanism to talk to Studio Artist from places like OpenFrameworks.
Or Processing for that matter if someone really wanted to do that.
So maybe this is a way to address Smm Samm's desires without getting involved in somehow becoming code dependent within Studio Artist on external projects like Processing or OpenFrameworks (which i don't see us ever doing, and if you think it through a little bit you would understand why i hope).
Any thoughts on what that external protocol should be based on?
I think starting simple is a good thing, and then extending it out over time if it really proves to be useful. So using external image files for moving images back and forth is not the most efficient thing, but is very straightforward.
Passing pointers to memory in external programs back and forth is a whole other ball game.
So, a rather easy way might be to open the protocol up to OSC.
OSC (open sound control) is a protocol for UDP messages and is widely supported by creative coding platforms (nearly all that I can think of).
It can send text, floats, etc... bi-directionally.
How I can imagine this being useful is be defining a JSON format that can be sent as a text block by OSC from a client to SA. Have SA respond that it was received, and respond again with another JSON message when complete.
I imagine that the JSON could include file-path, PASeq to run, resolution etc...
This structure opens up the option to run this on a small network very easily.
Of course, I would like an SDK, with DLLs I can link and interface directly, but this sort of REST API based on OSC, might be quick and easy... as well as rather flexible.
I lean toward OSC/UPD over TCP-IP just because of how easy it is to set-up in most creative coding environments.
I have done this with JSON over OSC in an app I built in Openframeworks before. I sent out large JSON blocks with all the body tracking data from a Kinect v2 camera.
It was very reliable, and fast.
We're looking at JSON already as one potential approach to modernize our SA specific file formats. XML as the other potential option.
We use IFF formatting right now, which was the obvious choice when Studio Artist started out, but i probably would not have gone that route if i was starting from scratch today.
Nice, glad to hear you're considering these things.
XML is nice, but a little heavier weight, and not as widely known/used these days.
JSON has kinda taken the web by storm.
I would love to test out whatever you have when you have it ;)
-
1
-
2
of 2 Next