Jump to content

drawflies

Members
  • Posts

    18
  • Joined

  • Last visited

Profile Information

  • Gender
    Not Telling

drawflies's Achievements

Apprentice

Apprentice (3/14)

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

Recent Badges

0

Reputation

  1. Thanks for replies. I've gotten some better results - not perfect, but will give the additional suggestions a try. Question: For typical (well done) app icons that are shown on desktop, or copied from desktop to an Explorer folder, when you click the icon in Explorer & a larger image (thumbnail) is displayed at bottom of Explorer, what ORIGINAL size icon is Explorer using to display that thumbnail? That may be one thing I DON'T understand - which original image is used for the Explorer thumbnail & if / how it's resizing or resampling it before displaying a thumbnail of icons. It may be using the 256 x256 icon & down sizing it a bit. Some apps' thumbnails that have round / rounded surfaces, look 100% smooth; other professionally ? done apps' thumbnails - not so much. When I look at all of the icons for those apps w/ Resource Hacker, import various sizes into PDN (or sometimes open an ICO file), few of those icons appear to use much (visible) shadows. Not of one color, anyway. Maybe they are, but I can't detect it. But, enlarged a bit or a lot, they're quite pixelated. I'm guessing for the ones that appear very smooth at normal size, they've used several shades & opacity of one or more colors, along the rounded / slanted parts, that give the optical illusion. Other high $ programs may have more powerful shading tools that would do that "automatically." PDN does that to some extent when drawing rounded shapes - using various opacity of pixels along the edge. Drawflies wrote: "but of course pixels are square..." Huh? is that really what you meant to say / for it to sound? Thanks. Ego Eram Reputo - thanks. I'll try that. Obviously, I've gotten different suggestions, which may all work under right circumstances & with right amount of experience.
  2. Thanks. I see that shrinking doesn't work well on detailed images, w/ elements that start getting divided into fractions of one px. Of course, elements could be drawn large enough on the original to allow shrinking & not have fractions of 1 px. It's weird - when click or copy / paste the link you gave, the page flashes quickly, then get a "sorry, page not found." But, I searched for the thread # & found it that way. I'll have to try starting w/ a small size (when 1 or 2 px wide elements are involved) & enlarge to see how that works. Otherwise, I'll just be duplicating each layer process for each image size. Sure, if I was Mozilla, it'd be well worth the time.
  3. "The water's cold - there's a lot of shrinkage."... George Costanza. Yes, I see that scaling it down (at least not in these programs - PDN, Greenfish, etc.) don't produce an exact, smaller duplicate. Obviously,the resampling doesn't help when it gets to these small of sizes of elements - dividing 1 px wide element by 4. What about in a case like this, starting w/ the 16 or 32 px size, design it & then enlarge. Short of editing each size, seems it'd work much better enlarging small elements than shrinking them.
  4. Whether just dealing w/ a png file (resizing) like attached, or converting to smaller sized icon, for the most part it eliminates the white circle, when reduce to somewhere around 32 x 32 px. Maybe this is because the reduction makes the given element too small to reproduce? But, in the reduced versions, there are PARTS of the white line that are clearly visible - but not a solid white line. So if it shows part of the line, as an intermittently dashed line, why can't it show the entire line? The image was created / saved at 32 bits. It's not only a problem dealing w/ icons - it's reducing png files as well. I'm thinking it may be better to start off w/ an image close to the finished size. But w/ icons in one icon file ranging from 16 to 64 & even 256 px, that's hard to do. Thanks.
  5. If either creating icons in PDN or importing some already made, that may be used on desktop, in Explorer, etc., should you go ahead & select in PDN to merge images of 48, 32, 16 px into one file? Assuming you've installed the save to ico plugin. If I save in only 16 px & use that in an Explorer folder of shortcuts, it looks OK - until select that shortcut / file, then it looks awful in the thumbnail (if turned on in Windows). That plugin automatically selects the 32 & 8 bit icons for a given size. What would the 8 bit versions be used for on a modern computer w/ HD monitor? Thanks.
  6. Thank you. Looks like a very nice plugin pkg. I saw it mentioned, but at 1st I was confused by your comment on Blur Selection Edge. I guess your web page http://www.boltbait.com/pdn/ is a bit outdated - it doesn't mention the Blur Selection Edge effect, but is mentioned in the topic http://forums.getpaint.net/index.php?/topic/8318-boltbaits-plugin-pack-updated-december-12-2011/ Like me, running a bit behind? Question: When using your blur selection edge effect, if a drawn / cut out object is by itself in a separate layer, on a transparent background, do you have to physically select the object outline to apply the effect? Or, since it's the only object in that layer, does it automatically select the object outline - even if irregular?
  7. Thanks - I'll give them a try. There are a lot of plugins. Like I said, no basic antialias effect built in. I'd think far more people would use that than some of the other features. Sometimes I would save directly from PDN to .ico. Others, Greenfish & IcoFX have (quick) features just for icons that PDN doesn't. Edit: Tried Basic Antialias - didn't do anything on circles drawn in PDN. I suppose because of author's description: http://forums.getpaint.net/index.php?/topic/7644-basic-antialias-version-11-bug-fixed-january-14-2008/?p=114888 It may work in other cases, but all totally opaque pixels drawn by the ellipse tool, already have semi transparent ones next to them. Even though some transparent ones are BARELY so, they have enough opacity to keep the plugin from working. So the tool takes no action. However, at 32 px, the jaggedness of a circle drawn by PDN (w/ no other effects) is still slightly visible. If I draw the circles at much larger than desired final size, then reduce it, doesn't seem to make much difference in pixelation. If I draw it at smaller size - say 16 px, then resize to 32 px, it reduces pixelation but has a definite fuzzy look, w/o running the antialiasing tool. In last scenario, antialiasing tool still has no effect. Greenfish has a soft blur effect that somewhat reduces the pixelation. Not perfect on a circle - which has continuous pixelation.
  8. Searching for how to simply, quickly smooth round edges, I learned a lot of other things I'd been wondering how to do in PDN. But I didn't find a simple way to smooth round edges of non professional grade (not art) round outer edges. Say, for a Windows icon. Even drawing the circle on a 32 x 32 background, when saved as png then opened in Greenfish Icon Editor & converted to ICO, the real icon (say on desktop) is still a bit jagged in places. The points at 0, 90, 180, 270 deg are obviously flattened & rest of circumference is a bit jagged (not terrible, but...). I tried several tools to smooth edges a bit, but of course pixels are square... Read numerous posts - like http://forums.getpaint.net/index.php?/topic/12195-faking-soft-brushes-and-the-blurdodgeburn-tool/. This WAY overkill for what I'm doing - right now. Useful for later. All I want is circles or rounded corners on simple objects w/o spending much time - not for this type stuff. I learned good techniques useful for higher quality work. PDN doesn't seem to have a simple, quicker way to half decently smooth circles / corners. Everything I tried just followed the square pixel edges or is quite tedious. Greenfish has some pretty decent tools - for making icons. But, smoothing rounded edges for something in the 32 px wide range is still pretty time consuming. Needs an algorithm to smooth circumferences. Any suggestion for quicker methods for non demanding work like this? Thanks. Pixels are square, but Pi ®squared, too.
  9. As I under stand, pixels wouldn't simply be "cut" or 2 laid side by side, if reducing or increasing size by 50%. That's where the "resampling" comes in. I'm no expert on that process, but it involves algorithm(s) - there are several. This article goes into more detail. https://en.wikipedia.org/wiki/Pixel#Technical Another possible issue for me & "actual resolution" is, I have Windows system resolution - "dpi" (though, strictly speaking that's for printing) set = 110, vs std. 96. So I can better read Windows' menus & such. How much, if at all, that affects displayed resolution vs. stated resolution in PDN, etc., - don't know. I suppose it depends on each app - whether they use the OS's PPI (dpi) setting. It certainly affects SOME text size in Fx. The Vista setting says "adjust FONT size." If it truly changes ONLY font size, it wouldn't affect images. I could easily check by physically measuring a graphic element at 96 PPI (sorry, Windows) & at 110, 120, etc. There's probably info on that issue, already. Side question. Do others see smaller displayed font size in the reply composer window on this forum, than that displayed in submitted posts? I do - here & on a very few other forums - but not many. Could be a Vista thing. But has to be related to specific forum software, as rarely see this issue.
  10. pdnnoob, good to know. IS dpi = PPI ? I'm not sure. You're saying PDN always displays on-screen images at 96 PPI? Obviously, it lets you change it - I suppose for printing. I understand about reducing each zoom by a factor of 50% . I didn't know it made a diff in the way (quality, accuracy) images were displayed. The zoom selections in PDN don't follow what you said. Those pre selected values may be just for convenience. But, wouldn't the accuracy of resampling - at any zoom - depend on the algorithm used, not the zoom of 27% vs 25%? There may BE a problem, as you said. But the computer / algorithm should be perfectly capable of dividing the original pixels by any value desired.
  11. Thanks to you both. I'm making it more difficult than it is. I've learned several things today. 1) Don't tell my wife the truth if she asks how pants make her look. 2) For an engineer & a math teacher & long time math tutor, I must be loosing it. Sad - just sad. Yes Daniels, your solution was correct. My only defense for not figuring it out, is I'm on heavy pain meds. That said, IrfanView (no, this isn't the IV forum) does something odd when I resize the cropped image. It retains the height of the cropped image, after resizing to 44%. But the length changes just a bit after resizing. May be close enough for gov't work, but odd. PDN maintains same on-screen L x W dimensions after resizing by to the same % that's shown as current zoom. pdnnoob - your comment gave interesting insight into different options / methods available when resampling. I knew they were there - never thought about them. Now, I'll have to read up. Thanks. Other thing caught my attention in PDN resizing options, is the PPI. I know what it is; even calculated it for my monitor. Don't know if it affects PDN ON screen images. Default PPI value = 96 when open resizing screen. My monitor is ~ 103 PPI (rounded). Changing the value changes the shown print size, but I don't know if using 96 vs 103 PPI affects images on screen. It didn't seem to change size of the image I rezized at 44% - using 96 or 103 PPI. Did show noticeable difference in print size.
  12. A bit unusual. If I load a large image (say 5400 px sq.) in Paint.net (or similar) & choose a zoom level where I like the look / size of individual elements, in ONE area. Image is still no where near 100%. I select a rectangle so the ACTUAL size of rectangle_AND the way the selection looks AT THAT ZOOM level, is what I want. Say, to use as Fx header background. Problem I've had: Because the image I initially cropped wasn't at 100%, when crop it - the PHYSICAL size of the rectangle may be 1920 x 180 px, but the prgm still thinks / knows it's really 3500 x 450 (or such), at 40% zoom. I can't just save the image - as it looks on screen - & it be that size when reopen it. I DON'T want to resize / resample it, because (sometimes) that changes the current look (size of certain elements in the image). The only way I've found (gotta be another way) is take a screen shot of the cropped image, at it's CURRENT zoom level. Then it will save as a 1920 x 180 px image, NOT as a 3500 x 450 px image that was at reduced zoom. If I resize & save at a REDUCED %, it can change the look & size of elements. Every thing I've tried to save the image - at it's PHYSICAL size on screen - say 18.5 in. x 1.75 in. (when image is NOT @ 100% zoom), results in saving a much larger image. I understand this, but looking for a way around it. Used various settings & tried to trick the apps many ways - cropping in one app, copying to another - you name it. Anyone know how to do this, other than screenshot - w/ ANY app? Cheers.
  13. I see in the online help file, under Toolbar > Choose defaults, seems to indicate (some) defaults for ALL toolbar items. This is entirely different from colors & palettes. I can't get it to save different defaults for separate tool items. It will set a default (say, Forward Diagonal pattern), but it only saves / uses values selected on the last tool item you open / make preference changes on. It then applies the last setting(s) made (say, for an ellipse) to all other tools. From Paint.net Help File: At least one other advanced drawing prgm (Inkscape) allows EITHER setting & saving individual tool settings (of all sorts) OR using Global settings for all tools (i.e., changing one setting - via global method - changes that setting for all tools). Is there any way to save a forward diagonal pattern for circles & solid line for rectangles, or save default for circle to draw shape outline, not filled, for ex.? Thanks. If it allows setting defaults (preferences) - at all - why for only one tool, or why (always - no other option) apply the same defaults to all tools?
  14. One concept that seems well accepted: just because a prgm works a certain way now, doesn't mean it can't be improved. It's done all the time. The option to save user preferences for ALL types of settings is a very desirable feature in software. If it wasn't possible in many prgms, users would be irate. two simple buttons - one to restore "defaults" (that I assume would set all tools to use the same primary / secondary colors. Another button / option to select a user's preferred color selections. Or just save last customized colors (or have a pop up, asking), & / or allow hitting "reset" if wanting all tool colors the same. Lots of prgms allow saving & naming multiple user customizations, in cfg, ini, js files, etc. Many allow naming & saving more than one customized preferences file, because they're so small. Users must be able to enter meaningful names, if > 1 file. This is extremely common. If you make customizations in browsers, word processors, pdf readers, do you have to (or want to) reconfigure those every time prgm is restarted? No, but AFAIK, that's the way Pdn works now. I thought I made that case - maybe wasn't clear. Depends on WHAT you're doing. Many times (not necessarily for artwork), I would want, say, arrows = purple, rectangle outlines = red, filled rectangle boxes (to enter text in) = yell, text to enter onto rectangles = red, etc. Just examples. Even IF using only couple colors & switching back / forth between, say - text & arrow. Makes no sense to continually have to reselect desired color for each, every time you switch - ESPECIALLY in same session. If you WANT to use several color for arrow in same session, click them. I'm betting in ONE session on ONE image, majority of users pick an arrow color & don't change it - for that image / session. NOw, switching back / forth between tools, using diff colors for each, must reselect (red) each time reselect arrow. How is that not unnecessary clicking for majority of users? It'd be nice if could store more than one customized tools color choices in named files. Also, quite common in many prgms, for instance - media players. * I see no sense in ALL tools being set to exactly same colors via choosing primary / secondary colors. * How many actually use same colors for ALL tools in a session, vs at least some diff colors for some tools? * Seems to cause extra work, after setting custom colors, for Pdn to revert to black / white after restart. How many use black & white for everything? 1) Do the plugins need P / S colors to be ALL the same for every tool? There'd still be P / S colors, just allow users to customize, or allow users to click "default" button to set them all the same again. Current color picker doesn't retain color choices between sessions, EVEN selecting P / S colors, & save as new file. When reopen that saved file, color picker P / S colors are reset to black / white. So unless I missed something on how it works, I don't get your point. It may retain changes made ON the image, but doesn't retain color selections in the P / S color boxes. Doesn't make sense to me. If want to continue your work on that image, using EXACT color picker values previously set, why would one want to RE select them (find the exact pixels - AGAIN)? Seems like more wasted time, by Pdn not saving previous settings, even for saved, edited images. Not an expert, but why would color picker need a complete remake? If you select the tool now, it changes P / S colors, depending on R or L click. Why would that need to change? It's a different tool w/ very diff function from most others. If you select it, you expect it to behave differently for changing colors. Now, if you use color picker to change P / S colors, then close Pdn, it reverts to black / white.
  15. I don't get it. How many want every tool available to (generally) always be the same color (like all red)? Maybe some do, but I don't know why. How many times out of all uses do you actually want every tool to be red or yellow? I still say the change I'm proposing wouldn't take more time for "color changers," and save a lot of time for those wanting to use different colors for different tools & generally use those more often than not. Even if color choices were saved session to session, if you want to select a new color, you only have to click - the same as now. No difference. Though it seems less likely users will want all tools to be the same color, I guess a "global" color selection button could be added - to set all tools to the newly selected color - over riding individual tool color selections. Even if there was a way to select colors for each tool & save it as a palette or config file, that allow users to immediately load their personal choices for each tool. Whether they were all the same or all different colors.
×
×
  • Create New...