Jump to content

MyrddinE

Members
  • Posts

    10
  • Joined

  • Last visited

About MyrddinE

  • Birthday 01/01/1970

Recent Profile Visitors

The recent visitors block is disabled and is not being shown to other users.

MyrddinE's Achievements

Rookie

Rookie (2/14)

  • First Post
  • Collaborator
  • Conversation Starter
  • Week One Done
  • One Month Later

Recent Badges

0

Reputation

  1. The color balance tool would be FAR more useful if it rotated the hue 180 degrees from the given color automatically. For example, take these two product images: The second image, while it happens to match the background of this forum pretty well, looks pretty bad on a white-background website. To get all of the products to match, I'd like to white balance the blue tinted image. Your tool is extremely helpful! But it has one horribly annoying issue, which I shall explain. Now, to white balance, I use the dropper to select a color from the background that should be white. With that color selected, I go to your color balance tool, and then click the selected color (from the top left by default), and click Ok. Done, right! Noooo! But... maybe it's just gray? I'll adjust the brightness and contrast (in this case, by 7 each)... No dice. The color is simply not balanced. In fact, it was shifted farther in the blue direction. The problem is that the White Balance tool is adjusting, by default, in the wrong direction. It should be adjusting in the OPPOSITE direction of the selected color, in order to shift that color to white. We can do it ourselves, by adding or subtracting 180 from the hue control in the white-balance utility. Using the same selected color, but subtracting 180 from the hue (going from 206 to 26 in my example), and click ok with no other adjustment, we get this: Still gray, but it's GRAY. The blue tint has been removed. We can see this when we do the same brightness and contrast adjustment as before: So my recommendation: Please rotate the hue by 180 automatically. There is little to no purpose in adjusting an image farther away from white... which is what this utility currently does by default. A simple change would make it far more useful, especially for people who are kind of hazy on how to adjust white balance manually.
  2. Having vectors remain would be nice... but I was trying to find a suggestion that was minimally invasive (easy to implement, acts the same way as the program does now, etc), rather than the best possible implementation. Something that would be easy for the creators to do, but still useful for all of us. The idea is to have a 'good enough' solution for Paint.NET, rather than a post begging that they make Paint.NET 'more like Corel' or 'more like PSP', with all the hundreds or thousands of changes required to do that. Paint.NET can't be like those big commercial packages, not with only two developers.
  3. Paint.NET cannot make animations. You could create the individual frames in Paint.NET, but you'd need a different program to collect those frames into an animated file format like ANI, GIF, or APNG. I use Animation Shop (which came with older versions of Paint Shop Pro). I'm sure there are free alternatives out there as well, but I haven't needed them, so I didn't go looking for them.
  4. Building a SWF would be kinda useless, since Flash is primarily a vector format. There are already flash objects you can use where you can provide the URL to an image, and the flash object will let you display, zoom, etc the given file... what else would you do with a picture embedded in flash? But I'd like to see Animated PNG (APNG) support too. Animation requires an entirely different GUI though, so I don't expect to see it anytime soon. Even if all you did was use each layer as a frame, how would you specify the frame lengths? I think that kind of stuff is best done in an external program, similar to how Paint Shop Pro had the external app Animation Shop.
  5. Ahh, sorry... the other posts did not look like a continuation of the rules, so I only read the topic post. Perhaps the post could be made more clear? All the rules put in one post, rather than spread through the entire thread? It's not very friendly to new readers. I was able to track down Crazy Man Dan's comment about multi-segment lines, but it was rather brief (unless there was a better post he made on the same topic); it didn't describe how it might function, or what problems might be encountered implementing it. I think my post was a useful contribution. Edit: This is a whole lotta blather about HOW I posted... doesn't anyone have a comment on WHAT I posted? Before the poll was removed, 7 of 9 people thought it was a good idea, and only 1 didn't like the way I described it. Doesn't anyone have an opinion worth posting?
  6. Sorry, the 'no polls' rule wasn't in the rules post. Perhaps that should be amended?
  7. I didn't see a request for this in the 'commonly requested' thread, nor did I find it skimming through the first three pages of posts.And there is no such user as 'CMD', nor someone on the forum whose login starts with CMD. Perhaps you could clarify, so I could find the post? Maybe a link? If the post is over three months old, it would have been necroposting to dredge it up again anyway.
  8. Umm. While I appreciate your support, I have no Idea what my post has to do with cutting or copying irregular shapes... I'm discussing a modification to the line/curve tool, not a change to the selection tools.
  9. I'd really like to see lines that are longer than just two endpoints with two control points. Multi-step lines with several midpoints and control points would be greatly appreciated. You could continue adding extra segments to a line as long as you held down shift when you clicked. After you had all your segments, you could go back and move points and control points around. This would require a few improvements to the GUI for controlling lines however. First, you would need to be able to switch back and forth between on-line control points and off-line control points (per segment). The simplest thing would be that if you moved a control point it would switch that segment to the correct type that matches the mouse button you used... rather than the type of segment being fixed depending on which button you FIRST used to move it, it would depend on the LAST button you used to move it. It should be noted that this improvement would also benefit the current single-segment curves. Second, you would need to be able to specify whether connections between segments were smooth or sharp. I think the most consistent method would be to use right and left click just like you do for control points... if you move the point joining two segments with the left mouse button, it is a sharp join. If you move the point with the right mouse button, it's a smooth join (curve). Smooth joins would mean that moving the control point on one side of the join would automatically move the control point on the other side of the join (to keep the join smooth). If a join was changed from sharp to smooth, one of the control points (probably the one downstream from the join) would have to be moved to be in-line with the other point. And third, you would need a setting for how sharp joins should be drawn... as an angle, as a curve, or not at all (a gouge). Finally, moving a segment join should move the two control points nearest to that join as well (the control point just upstream and just downstream). I'm sure there's some design questions that I left unanswered. The join between two on-line segments is easy (the join acts just like another on-line control point), but the join between an on-line and an off-line segment is harder... I'm sure it's doable, I just don't know how. There are also some visual effects that would likely need improving. Control points could be made into circles, while joins stay as squares. Or they could be circles and squares depending on what type of control-point or join they are (sharp joins and on-line control points could be squares... smooth joins and off-line control points could be circles), or perhaps other things like color could be used to differentiate. I think multi-segment lines are extremely useful (I know that *I* need them badly), and this post outlines the bare minimum UI necessary to implement them.
×
×
  • Create New...