Jump to content

skyoxZ

Members
  • Posts

    27
  • Joined

  • Last visited

Posts posted by skyoxZ

  1. On 8/24/2018 at 8:24 AM, Rick Brewster said:

    Please note that some of the updates to the translations were done via machine translation, and are not very good. If you'd like to help improve them, head over to https://forums.getpaint.net/topic/27847-official-translations-for-40-via-crowdinnet/ and make a post with your crowdin.net user name and which language you'd like to contribute to.

     

    It would be great if there's a filter for me to find all approved 0-vote translations not translated by me. Any suggestion?

     

    ps: Sorry for downvoting your translations. I was trying using "Need to be voted" filter, but it seems not practical.

  2. You might be able to work around this for the time being by adding a new layer on top of your current one and then using "All Layers" sampling mode in the toolbar. This assumes that you don't have other layers above/below that will get in the way. This should force transparent black and white to be equal values at the point where the comparison is made by the Magic Wand tool. (the math works out so that that blending transparent anything + transparent anything = transparent black)

     

    Seems not work. :(

     

    Edit: It works when putting the new empty layer below the current one. Thank you :D

  3. Whether it's a "bug" or not isn't really the point, in my opinion. The two questions that would guide me on this are, "what would you actually expect to happen" and "does it completely prevent you from being able to do something important/useful" (in other words, there's no workaround).

     

    Here is how I get the issue:

    In a new layer, I draw something and adjust the color using Brightness, Invert Colors, Delete or something else (the selection contains what I want to adjust and it also contains some full-transparent pixels which I thought it not matter to select them too). I have many layers like that. When merging these layers, I get a layer with some full-transparent but different-RGB pixels. Now I want to select all visible pixels in the merged layer (because I want to cut off the part of the canvas which doesn't contains anything). It seems like the best way is to select all of the full-transparent pixels and then Invert Selection, but it's not easy to do that.

  4. Sorry I don't know how to move my thread(http://forums.getpaint.net/index.php?/topic/108355-two-zero-alpha-aeras-are-treated-separately/), so I post it again:

     

    paint.net 4.0.9

     

    When using Magic Wand with a low tolerance (2%, for example) in a transparent white area, the adjacent transparent black area will not be selected.

    Paint Bucket has the same issue.

    I reported the issue 1 year ago (http://forums.getpai...ted-separately/) but it has not been fixed yet. I decompiled the program, and It seems that the issue is at PaintDotNet.Tools.FloodFill.FloodFillAlogrithm.GetDistance in PaintDotNet.exe. Wonder it is a bug or feature?

     

     

  5. I do not see this as a bug.

     

    We see 'transparent' as being visually the same. A computer does not see them at all. Instead it manipulates four 8-bit data channels (RGBA). Obviously #FFFFFF00 is not the same as #00000000 even though it appears the same to our eyes.

     

    I believe that the interpretation of tolerance is correct.

    /my2cents

    Technically, I'm not sure it is good to think color #FFFFFF00 equals color #00000000 but I believe the distance between two 0-Alpha colors should be 0.

  6. paint.net 4.0.9

     

    When using Magic Wand with a low tolerance (2%, for example) in a transparent white area, the adjacent transparent black area will not be selected.

    Paint Bucket has the same issue.

     

    I reported the issue 1 year ago (http://forums.getpaint.net/index.php?/topic/31721-two-zero-alpha-aeras-are-treated-separately/) but it has not been fixed yet. I decompiled the program, and It seems that the issue is at PaintDotNet.Tools.FloodFill.FloodFillAlogrithm.GetDistance in PaintDotNet.exe. Wonder it is a bug or feature?

  7. CodeLab 2.1 with paint.net 4.0.5288 has the same issue.

     

    I get some details if helpful:

    When running CodeLab, a thread is created about 1.5 sec before csc.exe being called. The thread would not exit until closing paint.net.

  8. I think it is an issue of paint.net.

     

    paint.net 4.0.5288 with CodeLab 1.8 got the same issue. Every time opening CodeLab, CPU usage increases by 8%, and the CPU keeps being used when CodeLab is closed. It significantly affects the speed of paint.net UI response.

  9. Win7sp1, Intel Core i5, paint.net 4.0.5288, CodeLab 2.0

     

    Every time running CodeLab will use about 8% CPU, even after closing the plugin. After several times of running CodeLab, the CPU usage reaches the upper limit of 25%.

  10. I also went through and approved all strings that somehow escaped my notice. I had only been bulk-approving new strings, but I missed the ones which had new activity (in other words, new suggestions). All revisions should now be correctly incorporated (as of June 22nd 14:00 Seattle time, of course).

     

    Here's a ZIP file with the *.resources files from all languages so that y'all can test it out if you need to.

     

    Is there any plan to go through all strings and approve the new suggestion? Maybe 4.0 RTM?

×
×
  • Create New...