Jump to content
You must now use your email address to sign in [click for more info] ×

Brush color wrong in RGB/8


Recommended Posts

Forgive me if i create a new post, but the older thread did not catch attention of moderators after several days and attempts.

I try to summarize the findings:

  • Affects iPad only, not Desktop
  • Affects Photo and Designer
  • Affects RGB/8 only, not RGB/16 (did not check CMYK yet)
  • When using a brush on a mask layer, or a inherent mask of an fill/adjustment/filter layer, the result is wrong.

Steps to reproduce:

  • Create an RGB/8 document, use sRGB color profile
  • Create any of the affected layer types
  • fill layer (alpha) with a gradient from 0 to 255 over the x-axis
  • Use basic paint brush, and set everything to default (100/100/100) for opacity/fill/hardness, blend mode normal, etc.
  • paint one stroke over white background (same layer!) over the x-axis

Observation:

  • The white brush leads to RGB 255 for old color value 0 to 127 (estimated)
  • The white brush leads to RGB 254 for old color value for 128 to 255

Link to video showing the bug:

 

 

PT visualize 3 color of CMYK.afphoto

Edited by NotMyFault
added test file

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

PT visualize 3 color of CMYK.afphotoIssue affects CMYK, too, but to a smaller extend.

Alpha values are remapped to C/M/Y from (253/254/255)

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

  • Staff

Hi @NotMyFault,

Thanks for spotting this. Issue logged. 

When you report bugs, can you please try and not overcomplicate recipes? These steps you posted in the other thread you mentioned are clear and simple, and the only things needed to replicate the issue. No need for any "helper" procedural textures or partially transparent fill layers when all it's needed is to brush on a fill layer. 

On 10/6/2021 at 8:53 PM, NotMyFault said:

Heureka, now I got it.

the issue happens by the following sequence:

  • create fill layer. Alpha = 255 per default 
  • use brush in black: alpha = 0, to remove any portion
  • use brush in white, to include back: alpha = 254 (wrong, this is the bug)

Issue not limited to fill layer.

same bug with a mask layer.

Definitely a bug on iPad.

@Meorge

Thank you again for spotting this issue, and providing all the input. Sharp eyes. I hope now the mods will rate this as bug and handover to the devs.

Link to comment
Share on other sites

1 hour ago, Gabe said:

Hi @NotMyFault,

Thanks for spotting this. Issue logged. 

When you report bugs, can you please try and not overcomplicate recipes? These steps you posted in the other thread you mentioned are clear and simple, and the only things needed to replicate the issue. No need for any "helper" procedural textures or partially transparent fill layers when all it's needed is to brush on a fill layer. 

Thank you for your reply.

I cannot fully agree about "overcomplicate", for the following reasons:

  1. The partial transparent fill layer is essentially required to understand and reproduce the issue. It shows how the white brush reacts to all 256 grey levels.
  2. Unfortunately the PT filter is required, at least for me personally, to be able to spot the issue on iPad in first place. It is almost impossible to see a difference between black (RGB 0) an almost black (RGB 1) or white (255) and almost white (254) with my eyes only.
  3. The iPad version does not provide an info panel or other means to directly check color values with out-of-the-box functionality.
  4. If you don't like the PT filter, it can be simply deactivated.

I spend quite some time trying to make it  as easy and clear as possible to reproduce, so it's a bit surprising and disappointing to hear my effort were unwanted. I needed a few days to fully understand and analyze the issue:

  • original report said affects fill layers, related to fill tool
  • understand how fill tool works on fill layers
  • find out that paintbrush affects inherent mask of fill layers (and not RGB value)
  • Multiple tries to understand if RGB or alpha causes the issue. Original report let me assume RGB, tests showed alpha.
  • develop PT filter to make issue visible for me, especially as it affects masks / alpha only, compensating for missing info panel on iPad (and Designer)
  • find out that all mask layers are affected
  • tried to see if pixel layers are affected (no clear results so far)
  • tried to find out which color formats are affected (RGB/8, CMYK)
  • Cross checked with Designer (same issue)
  • Cross checked with Deskop versions (not affected)
  • tried to reproduce issue in new documents, using as few layers and steps as possible.

I will try my best to follow your request, add some additional steps on my side to remove the unwanted tools before i file a bug report.

Have a nice day.

 

Mac mini M1 A2348 | Windows 10 - AMD Ryzen 9 5900x - 32 GB RAM - Nvidia GTX 1080

LG34WK950U-W, calibrated to DCI-P3 with LG Calibration Studio / Spider 5

iPad Air Gen 5 (2022) A2589

Special interest into procedural texture filter, edit alpha channel, RGB/16 and RGB/32 color formats, stacking, finding root causes for misbehaving files, finding creative solutions for unsolvable tasks, finding bugs in Apps.

 

Link to comment
Share on other sites

  • Staff

Hey NotMyFault,

Gabe and myself spent some time looking into the recipe you wrote above because initially, we did not 100% understand the post. Rather than just log a bug, we do tend to want to try and understand what is being reported as opposed to mindlessly logging everything we come across with the developers.

We can tell you always put time into reporting a bug as you always include steps, expectations, actual results, files and videos - we could not ask for more. However, in this instance, I think Gabe was simply suggesting that the shorter recipe in the thread he linked was actually enough. Often, some recipes can appear over complicated and as QA, we try and simplify recipes for the developers.

I also apologise for letting the other thread drag out longer than it needed to.

We do appreciate all the effort you put into your reports. You definitely go above and beyond, not only with your own reports but also when other customers report issues to us. So please do not be discouraged. Thanks again. 

 

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.
Note: Your post will require moderator approval before it will be visible.

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.

Loading...
×
×
  • Create New...

Important Information

Terms of Use | Privacy Policy | Guidelines | We have placed cookies on your device to help make this website better. You can adjust your cookie settings, otherwise we'll assume you're okay to continue.