MXI

Members
  • Content Count

    18
  • Joined

  • Last visited

Community Reputation

6

Profile Information

  • Gender
    Male

Contact Methods

  • Website URL
    http://mxii.eu.org

Recent Profile Visitors

514 profile views
  1. I agree about the icon - it doesn't need to be something as stressful as the red cross. But I don't agree about text change. Two "Don't"s will introduce equal amount of confusion. "Cancel" is the standard name for this behavior across all and every applications out there.
  2. MJW proposal to save tokens reminds me how VST plugins and hosts work in audio editing world. It would be great to be able to mark used tokens as presets and being able to open a plugin dialog with any of stored presets. It might have a form of a one level deeper menu - you either click the effect itself, same as before, or open it's submenu and choose from stored presets. In PDN plugins world, few plugins implementing their own tools to store presets now. For example, Measure Selection plugin. It seems like the OptionBasedLibrary dll is used there for this purpose.
  3. I had this issue. The few times when I needed to print something from Paint.NET, I used Levels adjustment to make image darker so it will look fine on paper. I have HP LaserJet P1005 if that matters. Paint.NET provides access to Color Management options for printing, where color profile can be set up for printers, like for displays. Maybe the defaults used in Paint.NET not good for everyone. And apps that have no such setting - get better defaults. If that's the case, then there better be a way to bypass this settings for average people who can't care less about color management and just want the damn thing to print good enough. And a comprehensible instruction how to use it for the rest of people.
  4. For something as simple as Invert (or even a bit more complex) there are batch convert tools in XnView/XnViewMP and probably other similar apps. Depending on the problem you're trying to solve, ImageMagick might be an option too. I doubt the batch processing has a high priority for a paint application. Although it won't hurt to be able to leverage the power of existing plugins in this way, of course. Reuse the manually created routine in an automated manner, without the need to look for filter analogues. Question to people close to Paint.NET inner workings: How hard will it be to make a CLI application being able to run ScriptLab presets?
  5. What can be done in plugin now: You select a color and a plugin modifies existing layer to leave only pixels with this color or pixels with any color except this. Of the plugins I have installed, - Unblend by ArgusMagnus can do the latter. - Color Accent by Kris Vandermotten sort of does the former (just desaturates the rest of image). - Color To Alpha (can't see the author) sort of does the former (fiddly controls). Maybe there are more. As for file type plugin, it might be something like existing ZIP plugin, with custom layer splitting logic: Speaking of custom logic: It might be viable to have just an external script using ImageMagick to modify the layers inside archive produced by existing ZIP file format plugin. I think this topic is somewhat related to as an industry-specific task that can benefit from better plugin API.
  6. I agree it's tedious. I should've accented this better, or rather dropped the second part of my comment completely. It was a digression from what I wanted to post here. I think this problem, among others, can have a better solution than it is now - through improvements in layers system. Rather than investing developer time into industry-specific system, provide a way for extensions to solve tasks like this in an efficient manner. If extensions will be allowed to produce new layers and blend them back in custom ways, - it will allow to create an extension to split image into color components with a single step and not being limited to RGB. (I'd love to have HSL for example.)
  7. Something similar to layers but separate from layers - looks excessive to me. There should be some way to mate this with layers... Recently I had few situations when I needed a way to recombine color layers. I'd love to see the layers tree, and new APIs that will allow custom blending modes and allow plugins to add new layers. Currently it's possible to extract channels one by one with "Extract channel" plugin from Ed Harvey effects pack. Clone the image to three equal layers, extract R, G, B on each layer (non-grayscale to keep color), make additive blend mode for layers, voila. No alpha though (another extension and some manual work will be needed to add alpha back), and editing might be a pain (need some accuracy with colors).
  8. But it isn't, as I'm thinking one step further already and all of you saying step one is enough. Hearing this from Rick instead of "Nope" would've been reassuring enough for me. But all I got is the same "Clipboard is enough for everyone" story. I consider myself a developer too. I understand there are time and effort requirements in implementing any feature. I can see some of possible technical difficulties involved, and that there are things like priorities and a road map. But nothing bad in discussing possible features and what paths they open for users. Let people think in terms of possibilities and evaluate their uses for new features. By the time the feature gets into development, there better be a good understanding of how and what for this feature will be used. The answer cutting any creative input and further exploration won't be beneficial for anyone. It might end up in a situation when formally implemented feature won't or can't be used by those who were seeking for it. If ever implemented. It would be really shortsighted not to see people will start sharing what is worth to be shared and possible to do so. Local thing? I'm not familiar with this abbreviation.
  9. You probably don't understand what I'm talking about. Clipboard is a workaround. A common interface you rely on when you don't have a better solution. Selections better be first class citizens in the app. With names. With the ability to keep and share them as a part of the project. Like layers, they are a cross-section of the project, can think of it as an orthogonal one to layers. In-app selections management will let you to provide a refined workflow for sprite sheets, UI kits, etc and spare artists time to figure out their own. Let alone saved time to switch contexts and get the right selection in place every time . Can't check the new Windows clipboard yet, but I bet it's pretty bare-bones, no chance to name things.
  10. I feel like I'm on some Linux users forum and all the best tools were already invented - nothing will ever surpass console and text editor (or even better, console text editor). Why should I build a complicated workflow for the things that I feel can easily be just under one click of a mouse? Granted, for now it's the only way to achieve the goal. But while new versions of Paint.NET are still made, we can shape it to be a better tool. So better look at it with open mind. I don't think this feature will be like fifth wheel or something. It will be a natural extension of what we got so far.
  11. The main difference is that Saturation and Lightness of HSL are more intuitive and easy to handle than Saturation and Value of HSV. "The HSL model attempts to resemble more perceptual color models ..." (as Wikipedia says) I have a pretty good intuition which slider and where should I drag in case of HSL. Lightness for amount of light, Saturation for how "clean" the color is. Normally I need either make color more clean or grayed while keeping brightness, or adjust brightness up or down in wide range without affecting "cleanliness". HSV has these features entangled - no way to achieve the result without twiddling with both sliders.
  12. HSV is so damn useless. Aaaargh! I'd throw it away without hesitation. I'd suggest to redesign Colors widget and make it pluggable, so people can design their sliders for whatever color model they want.
  13. To support the fifth request: I'd love to have Selections list (F9 for example) alongside with Layers list (F7), and have it stored in the PDN file itself. This will allow to use it as a sprite sheet - a single file with all the art pieces for a project. Less context switching, more consistency within artwork when it all in front of your eyes... A simple way to export all stored selections to files would also be helpful (point out to a folder and it will use selection names as file names). I can adapt https://hluk.github.io/CopyQ/ to manage selections, but it will always be less convenient than it should be.
  14. This question keep reappearing. And I came to this forum to leave the very same question, because I couldn't figure it out myself, without someone showing it to me. Similar questions: (these boxes taking too much space, distracting from the essence of the comment. I'd love them to be optional) Maybe there is more. This means there is a serious usability issue. Some solution should be found to improve discoverability of this feature. Also, I'm not quite happy with two-step process when exporting to file. In some cases it makes sense to have PDN and flat file to be opened alongside, in other cases it might be simpler/faster to do a single-step export. I always envisioned this as "Export to file ..." and "Export to clipboard" items in "File" menu.