Automation interface?

[BoYuan]

First this is not entirely related to scripting. I have searched the history and I know scripting is not yet available.

Today we are creating our own software based on c#, and we want to "export to ..." adobe photoshop and paint.net. In photoshop, we can use the COM interface api and start a session, create a new document, paste the system clipboard onto the new document.

How do I do it for Paint.Net? Can we call a managed exe file to start the application? How can we control the creation of new document and paste?

Thanks

[Rick Brewster]

Sorry, there is no automation interface of any kind for Paint.NET yet.

[reverse_atomic_roger]

Can I add my voice for this request?

It could also give the option to use powershell for scripting stuff, which would presumably allow a more stable and consistent use of scripts, as opposed to plugins which might stop working when Paint.NET updates.

thanks

[zarathoustra]

you still can start the app and open a picture with command line.

> PaintDotNet.exe picture.jpg

[verdy_p]

Can I add my voice for this request?

It could also give the option to use powershell for scripting stuff, which would presumably allow a more stable and consistent use of scripts, as opposed to plugins which might stop working when Paint.NET updates.

thanks

Given that Effect DLL's are exporting their entry points, nothing should prohibit automating them in a custom script, as long as these DLLs can resolve their own entries in the PDN library (which also exports some public APIs that Effect renderers can use to get some other environment properties).

I wished that there was effectively some effect description language, where you decompose it as a series of surfaces with given dimensions and relative positions (plus possibly some tiling mode for coordinates outside of the color planes width), and with the given number of color planes (not just the 32-bit BGRA color model). Then we would describe the renderers that we want to use: how many surfaces and which type of color model (how many color planes and which bitdepth) they accept, as well as their list of parameters. The described scene would then combine a series of input surfaces making the scene, into a ordered graph taking some surfaces on input, positioning them relative to each other, and would supply the reference to the effect or combinator to apply.

The output would be one or more surfaces. The graph would be directed and acyclic. Then the script would order the rendering and would submit the tasks to each effect renderer, managing the various surfaces and splitting them according to CPU/GPU ressources and a list of working threads. The input and output ends of the acyclic graph, could be left open to create a new composite effect, fully automated.

The script language could also provide some facilities to compute the parameters: dimensioning and positioning the images; aligning them according to some constraints; computing the parameters of some effects, or allowing them to be computed from elements located in some of the source surfaces, or from general input parameters. It should allow describing these parameters, in order to be able to build a GUI for parameters dialogs. Some parameters should also be bindable by default to some objects in the PaintDotNet interface (such as the current selection region, the color chooser, the ordered list of loaded images, or to a new image that PaintDotNet will allocate and prepare in its GUI. Some other facilities should be given, notably the possibily to bind some input or output surfaces to files named from string parameters; and the possibility to bing string parameters (such as filenames) to command line parameters (just assighn them a distinctive symbolic name) or to a file selector control ("Load image", "Save image as") if the string value of the named parameter is not specified.

Much later probably, it should also be possible to assemble a series of images/surfaces into a video or an icon file or an animated GIF or PNG, or some other file formats that contain ordered series of images, and insert/embed some other metadata information where it is needed by these formats, including possibly some synchronized audio streams. This would result into a great tool for assembling or treating videos, for example to assemble a scrolling text, or subtitles, or inserting logos on top of all images, or applying color transformations or cleaning/resizing filters, or to build composite mosaics of videos.

And may be the script language could be XML-based, for later inclusion on a web page (with a browser plugin). It could use other web standards as well such as CSS and Javascript (including other languages that can work on the XML DOM and retrieve and post various ressources from/to the web, such as some of the developed ML languages that allow working with 3D models, using the capabilities of the local GPU if available). The available effects would specified with an URL, and could even be implemented as a web service.

May be I'm dreaming too much here ! This would be very far from the initial PaintDotNet application, but PaintDotNet would be an element in that universe of graphic services, for working on local resources, but at least the best rendering effects should be standardized for use in various graphic tools (this will be possible only if we can build generic effects or renderers and image producers or image output feeds without linking them necessarily to some version of the PaintDotNet API). Ideally, the interface provided in effects should also be independant of the language or platform used to access them (so we could as well use some great effects available in other graphics apps supporting such interface, such as PaintShop, The GIMP, video editing studios, or much simpler media file editors/correctors/animators/...).

But the start point would be to generalize the API for custom effects:

Render(Surface[] in, Surface[] out, Rectangle rectScene, Rectangle ROI);

And conceptually:

Describe(Properties[] in, Properties[] out)

Where the output Properties would be used to indicate the number of required parameters and their type (surfaces, strings, filenames/URLs), indicate the number of additional work surfaces and the number of output surfaces, and describe the tree of composition, as well as a list of method entries implementing the Render() interface above and that would need to be instanciated for use in worker threads, as well as a list of rectangles in the described scene (passed as the rectScene parameter, which would indicate the valid coordinates within all the input surfaces), PaintDotNet making the job of mapping these scene coordinates to the actual coordinates in the input images (or using some composition mode like tiling, mirroring or a default color outside according to the scene description).

The custom renderer would then compute the ROI area within each output surfaces. Also the surfaces should offer more color mapping modes than just the 32-bit BgraColor (PaintDotNet would perform itself the necessary conversions needed to connect one ouput surface format from a given effect to the input of another effect, using its own sets of effects.

No temporary surface would need to be passed: you would just need to be able to describe the effects DLL so that it will describe several chained effects, including special effects that would just add some other empty surfaces, or drop one, in wich case, the Render() entry would perform absolutely nothing itself.

[Simon Brown]

In other words turn Paint.NET into a graphics library with its own browser plugin instead of finding/writing a good independent library for an existing language and using Shockwave/Java/Silverlight?

[verdy_p]

In other words turn Paint.NET into a graphics library with its own browser plugin instead of finding/writing a good independent library for an existing language and using Shockwave/Java/Silverlight?

Possibly this could be something quite similar to the Multimedia codecs API (audio/image/video producers and sinks, that you can also structure into an acyclic directed graph). Actually, it is not fully acyclic because there can be feedback streams, however it remains acyclic because feedback is only possible between separate synchronisation points, generally a fixed number of time ticks or some number of frames, so within a single synchronisation point, the directed graph if acyclic, and connected to the next processing loop after crossing the sync point to make some outputs become the inputs of the next step...