Fine changes in "color" window RGB value incorrect - Ruining greyscale RGB height map development image

[Grimlock]

Affinity Photo - Version 2.1.1

How I'm using the app:
Game design height map development
I am working with height data in greyscale with 256 values. I need to be able to pick up a color and then move the values up (or down) by one, mark, up (or down) by one, mark, and so forth.
Usage Example:, I press "I" click a pixel, 140/140/140 (RGB) is picked up. In the color window I use my scroll wheel to roll the RGB values to 139/139/139. I mark a line, In the color window I use my scroll wheel to roll the RGB values to 138/138/138. I mark a line. This process is continues to paint height, which will be used by other apps.

Bug experienced:
Even though the RGB value says "139" I apply it and continue to ramp my colors as described in the previous example. I get to say 130 in my ramp and then I export to PNG and then open with my height map viewer. I find that the ramp in not a consistent step as I carefully worked in the app. Instead I find that "139" was completely skipped and it's 138, leaving an error in the height map that I have to go back and fight to fix by playing with the color selection to get it correct.

Additional information on document and method used:
10240 x 10240
301 MB

Error occurs without any layers above it, no blending modes altering color applied. Painting is done with the pixel tool with all adjusters at 100%. All opacities, including the one in "Color" are at 100%. This is essentially pixel art at the macro level it is being edited.

I pick up the color with the eye dropper tool (I), and then use the mouse wheel over the RGB values in the Color window to scroll up or down.

I would like to note that I use the info tab to check RGB values and I find that the "Color" window RGB setting does not match the info window value, which would show the value off by one, correctly displaying it.  

Impact:

The discrepancy becomes obvious when I render the height map in 3D. Steps that will smooth out to ramps in the final game engine are not correct, nor are other edits using the above method. One pixel color value off places the resulting height map off by 1 meter in the game engine, not good!

This bug is ruining my work and wasting my time in a big way. Color control is a fundamental aspect of a graphics application, please look into this ASAP. If not fixed I'll have to use a different product, unfortunate because I like Affinity Photo. Please restore the trust, I want to believe this app is a solid PS replacement.
 

[NotMyFault]

Can you please upload an example document?
which color format do you use, GREY/8 or RGB? Those do not match 1:1, and you need to use the matching color mode in color panel for the document color format.

The info panel automatically converts between document and chosen color format, but for some cases the conversion is not accurate, e.g. CMYK info panel may ignore the document color profile, and use a default one.

[Grimlock]

Sample.afphotoSample.afphoto

I cropped it down to the latest item I was having difficulty getting the RGB values to cycle initially down by one value immediately after pulling the color up with the eye dropper. To help you understand what I'm using this app for I included a render of the tower draft.

Try to pull a color, then use your mouse wheel to move the RGB values down by one, then paint, repeat, create a step of say 3 or 4, then hover over those colors and look at the info window. You'll see that it's off by one..

I'm having an overall difficult time using this app for pixel art, I never had issue with Photoshop. I'm including a separate set of images "Pixel 1.png and Pixel 1A.png". This happens when I move the pixel art, it blurs.... sigh, I hope I just have a setting wrong in the app. Affinity Photo has been difficult to work with when getting down to the individual pixels. Colors not painting the value shown in the color window, pixels blurring when rasterized or merged... You all should include a "pixel art" setting in the menu that locks pixels down to a pixel grid and makes any other adjustment needed to keep pixels crisp. I've seen a lot of users posting about difficulty using AP for pixel art. I like this app overall, I'd really hate to move away from it because of pixel level issues I've been experiencing.

Thanks for any help you are able to offer.

Sample.afphoto

[NotMyFault]

Thank you for the test files.

Topic 1: Discrepancy Info panel / color panel

As explained before, the info panel ist not trustworthy for exact color values, except in special cases (e.g RGB mode, sRGB profile).

When using a GREY/8 document, there is no 1:1 mapping between GREY and RGB values. 

More serious, there is no way to inspect GREY values in info panel. If you set the info panel picker to „greyscale“, it shows percentage values, on an inverted scale based on K values.

The only way to correctly inspect stored color values inside Photo is using special procedural texture filters (i can provide later).

Similarly, specifying GREY values in color panel is limited to %, which won‘t exactly to convert to the 256 values stored in the file. Using RGB in color panel could lead to unexpected conversions (based on which color profile is used).

Photo has issues and principle limitations with color management.

Topic 2: blurriness by non-integer positions

This topic has been discussed in depth before in other threads. To avoid, you need to follow (not centrally documented) best practices wrt move tool, snapping options, view mode, when and how to rasterize, etc. 

Summary

It is possible to use Photo for pixel-art, but honestly it is not big fun based on countless UI traps and functional shortfalls like you observed with colors and layer fractional positions.

[NotMyFault]

Please find a test image below with PT filters who show a mask where pixel of a chosen color (variable a) are located.

The test image is a gradient from 0 to 255. So when choosing a, the column with the exact number gets highlighted in white-

If you place your own test file, you can exactly spot those colors.

 

The filter works both in RGB/8 and RGB/16.

GRAY8 bug color 255.afphoto

[NotMyFault]

On 9/18/2023 at 8:04 AM, Grimlock said:

Affinity Photo - Version 2.1.1

How I'm using the app:
Game design height map development
I am working with height data in greyscale with 256 values. I need to be able to pick up a color and then move the values up (or down) by one, mark, up (or down) by one, mark, and so forth.
Usage Example:, I press "I" click a pixel, 140/140/140 (RGB) is picked up. In the color window I use my scroll wheel to roll the RGB values to 139/139/139. I mark a line, In the color window I use my scroll wheel to roll the RGB values to 138/138/138. I mark a line. This process is continues to paint height, which will be used by other apps.

Bug experienced:
Even though the RGB value says "139" I apply it and continue to ramp my colors as described in the previous example. I get to say 130 in my ramp and then I export to PNG and then open with my height map viewer. I find that the ramp in not a consistent step as I carefully worked in the app. Instead I find that "139" was completely skipped and it's 138, leaving an error in the height map that I have to go back and fight to fix by playing with the color selection to get it correct.

Additional information on document and method used:
10240 x 10240
301 MB

Error occurs without any layers above it, no blending modes altering color applied. Painting is done with the pixel tool with all adjusters at 100%. All opacities, including the one in "Color" are at 100%. This is essentially pixel art at the macro level it is being edited.

I pick up the color with the eye dropper tool (I), and then use the mouse wheel over the RGB values in the Color window to scroll up or down.

I would like to note that I use the info tab to check RGB values and I find that the "Color" window RGB setting does not match the info window value, which would show the value off by one, correctly displaying it.  

Impact:

The discrepancy becomes obvious when I render the height map in 3D. Steps that will smooth out to ramps in the final game engine are not correct, nor are other edits using the above method. One pixel color value off places the resulting height map off by 1 meter in the game engine, not good!

This bug is ruining my work and wasting my time in a big way. Color control is a fundamental aspect of a graphics application, please look into this ASAP. If not fixed I'll have to use a different product, unfortunate because I like Affinity Photo. Please restore the trust, I want to believe this app is a solid PS replacement.
 

The issue is cause by using RGB/16 format (instead of RGB/8).

The color values are somewhere between 139 and 140 (using 16 bits), probably it was a gradient. So info panel rounds these values.

Set the color panel to 16 bit resolution, and use the sampler to get accurate values (divide by 2^8 or 2^16)

If you want to use the info panel, use RGB/8. Otherwise it is useless, as it will round color values to 8 bit, and it seems buggy rounding up or down for same color values.

 

 

[Grimlock]

EDIT: I wrote this without seeing your other replies, I'll read them now...

"This topic has been discussed in depth before in other threads. To avoid, you need to follow (not centrally documented) best practices wrt move tool, snapping options, view mode, when and how to rasterize, etc. 

Summary

It is possible to use Photo for pixel-art, but honestly it is not big fun based on countless UI traps and functional shortfalls like you observed with colors and layer fractional positions."

Can you please ask the staff to write a detailed set of best practices for pixel art when utilizing AP.

Regarding topic one, I'm finding that the info panel is correct but the color selection window doesn't do what I want. If I go RGB 140/140/140, then switch it to say 135/135/135 with the mouse wheel in the color selection window, then I check and it's not 135 after applying the color. I can confirm this when I render the height map, or by simply pickup up the color with the eye dropper tool. There is an issue in the software that should be investigated.

[Grimlock]

I'm having trouble with this again. I switched to 65535 grey 16 bit for the brush tool. I can't seem to type in a color value, paint it, and then pick it back up with the eye dropper tool to confirm the value it painted. It's not accurate.

Example, I need 27807 and I type that number in. I paint a spot with the pixel brush. I then click it to pull the color with the eye dropper tool and it reads 27713... That's off by 94 which is really bad for my work, like it ruins it. Is there something I can do to make this work because I'm losing trust in this app. Simple color stuff should be fundamental for an app like Affinity Photo. 

For context, a range of 256 of 65535 = 1 meter in dimensions for the game engine I'm working with. So being off by 94 in other circumstances would be fine, I need precision. 

Side question: Can the info panel read 16 bit? If not, is that not something the developers can program in? Limited functionality of something like an info panel would be expected from something like Gimp, not a paid for app like Affinity Photo. Maybe mention that to the devs, get the info panel fully functional.

Thanks for any help you can offer.

[NotMyFault]

2 hours ago, Grimlock said:

and then pick it back up with the eye dropper tool to confirm the value it painted.

Did you set it to 1x1px sampling size? Please try the color picker from tools panel (left), not the color picker from color panel (right) which averages over 3x3px, more info https://forum.affinity.serif.com/index.php?/topic/187254-color-picker-picks-wrong-colors-v21-1799/&do=findComment&comment=1092499

Can you provide a screen recording showing the exact steps, and upload an example file, saved with history to cover the before and after state?
 

 

Color picker and color panel have their quirks, especially when mixing color formats (which happens unnoticed in case of using swatches.

[Grimlock]

Thank you for the reply. I'll try as you instructed.