Jump to content

Shifting colors


Go to solution Solved by BoltBait,

Recommended Posts

The color painted by bucket/gradient tool (maybe applies to others as well, didn't test), shifts by one (almost always down by one).

So, let's say, I painted a background with HSV 0,0,50 (gray) and then do some work. When I select color picker and click on background, it shows V as 49 !!! It is not only for "show". The color really shifts. The same often happens when I switch two predefined colors in the color window. The trend is to go down, not up. (V values tend to go one down).

If it doesn't happen on first try, you're lucky, try a few more times.

Even more disastrous is that this also happens when merging layers, causing me to loose precise work. When I merge layers, two images with 0,0,50 backgrounds, being in overlay mode, suddenly produces 0,0,49 result after overlay mode merging. I had to bucket "several" times to remedy. But, this is no good since the workspace I have generally have very close colors (0,0,49 on 0,0,50 background, for example).

 

To reproduce this easily, paint a background with #808080 (0,0,50 hsv), select secondary color, bump V by 1 (51), do some random brush on the picture, then try clicking primary and secondary colors a few times to see their values first, then check color picker on background, rinse&repeat.

 

The more work you do with colors close to each other, the more shifting tends to happen.

Edited by Dolce Saito
Link to comment
Share on other sites

Paint.NET is a bitmap editor that uses the RGB color space.

 

The color docker window allows you to specify colors using the HSV color space.  This is only offered as a convenience to users as there is no direct translation between RGB and HSV (and back again).  That's why these very small "off by 1" errors happen.

 

This is a "known issue".  While much work has been done in this area to minimize the effect, it will not be fixed.

 

If you need to do precise work with specific colors, use the RGB sliders to choose your colors. These will always be consistent.

 

Link to comment
Share on other sites

HSV is more human-intuitive in many aspects. What's the twice as saturated version of RGB 109, 178, 153? I don't want to calculate or eyeball that, but changing the saturation slider from 38 to 76 to get RGB 42, 175, 126 is simple enough. What's the violet version of equal saturation/value that color? Add 120 hue to get the next primary color to use as the basis.

 

The downside is, as demonstrated, the mapping to RGB isn't 1:1 (in PdN, RGB has 256*256*256 combinations, HSV has 360*101*101, which is around 22% of the total RGB space), so you can't expect colors chosen in HSV to be exact or unique to a given RGB value.

  • Like 1
  • Thanks 1
Link to comment
Share on other sites

I see, but what if I only worked on hsv colors, without touching rgb at all?

 

I set hsv: 0,0,50, and my work range is generally gray level 0-51, mostly between 35-51. Only grays. Would it be a valid "known issue" if I only use hsv values all the time? I see where you're coming from, but unlike in your examples, I am not using palette at all, directly working 0,0,50 then 0,0,49 or (0-51V), not even touching rgb.

 

If calculation doesn't change on the fly, setting V:50 shouldn't shift to V:49 next time I switch to primary-secondary colors, if I started from point where I only changed HSV values.

 

I think system is calculating rgb from hsv, then converting rgb back to hsv in order to show it there in the color box, where it looses precision and shifting occurs. (Converting from 1.10f to integer will yield 1, then returning to float again would yield 1, loosing precision). Probably something similar is happening.

Edited by Dolce Saito
Link to comment
Share on other sites

10 hours ago, Tactilis said:


For my education, why do you choose to select colours in HSV rather than RGB?

For displacement maps. The median (leveled out) value is set by environment to 0,0,50 constant and the displacement depth is based on 0-100V. Where 0-51 (52 at most) is my working range.

 

Also, as frio said, it is very easy to calculate, imagine and mapable to use it. 0-50 is very human calculable then 0-128 given the scenario I have.

Edited by Dolce Saito
Link to comment
Share on other sites

  • Solution
31 minutes ago, Dolce Saito said:

I see, but what if I only worked on hsv colors, without touching rgb at all?

 

You can't.  Paint.NET is a bitmap editor that works in the RGB space.  This means that Paint.NET stores the working bitmap in memory in the RGB color space, all the effects work on the colors using RGB math, the blend modes all work on RGB values, and it saves the image using RGB pixel values.

 

The color docker window allows you to specify a color using HSV, but as soon as you do, it is converted to RGB for use.

 

There is no accurate conversion back-and-forth from HSV to RGB.  There are always small rounding errors introduced.  Allowing you to specify a color using HSV is only a convenience to the user--the value is immediately converted to RGB for use within Paint.NET.

 

  • Like 1
Link to comment
Share on other sites

Join the conversation

You can post now and register later. If you have an account, sign in now to post with your account.

Guest
Reply to this topic...

×   Pasted as rich text.   Paste as plain text instead

  Only 75 emoji are allowed.

×   Your link has been automatically embedded.   Display as a link instead

×   Your previous content has been restored.   Clear editor

×   You cannot paste images directly. Upload or insert images from URL.

×
×
  • Create New...