Jump to content

Anti-aliasing question and challenge


Recommended Posts

Hi,

while experimenting again with anti-aliasing (AA) I found a question, and I have a challenge.

  • Question (possible bug): having a document in lab mode, blue background, white rotated rectangle above, the AA-edge gets into pink colours. I would expect blue colours with increasing share of white, but no hue shift.
  • Challenge: using 2 adjacent rectangles, is it possible to adjust the distance between both rectangles to get symmetrical colors of AA-edge pixels? In my tries, the colors of "touching" edge pixels never match.

 

Screenshot 2022-06-21 at 21.25.31.png

AA challange.afphoto

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.

My posts focus on technical aspects and leave out most of social grease like „maybe“, „in my opinion“, „I might be wrong“ etc. just add copy/paste all these softeners from this signature to make reading more comfortable for you. Otherwise I’m a fine person which respects you and everyone and wants to be respected.

 

Link to comment
Share on other sites

Interesting. I think the pink is not an issue of Anti-Aliasing but rather of the LAB space, respectively the LAB model and its translation as interface with only three straight sliders.

Different to the HSL model where saturation and lightness are separate and each hue can have black / white

181188556_HSLgray.jpg.b280c63feda86689be0fad2e6b94c99b.jpg  1799058995_HSLwhite.jpg.571207efe15c6c5d647727369aae0cde.jpg

… the interface for the LAB model has black / white only for 1 certain 'hue' setting: A = 0 and B = 0:

150075241_LAB50-0-0gray.jpg.f655378bb8bbcbae8b9273d2f3e6a09d.jpg  1752365180_LAB50--42-0green.jpg.ce93ed3853c9332318318505c40e60de.jpg  399710119_LAB100-0-0white.jpg.e701e80cafb2bda4e5e9910991b0f743.jpg

See what happens if I increase L (lightness) of your Fill Layer from 30 to 100:

705768564_LABblueL30.thumb.jpg.d92e34eda965b1fa7708b92da61d4620.jpg

1551376591_LABblueL100.thumb.jpg.10764880a4421bdc80c710199dc3e38c.jpg


Another sample:    LAB blue tints.afpub
Tints of a LAB blue. Note in the Colours Panel the different colours in the slider (~white) versus the round colour well + applied colours (~cyan):
According to the LAB globe model I would expect the LAB slider for L = 100 would result in White colour, for every value of A and B.

196251750_LABbluetints.jpg.16371b99abc8ca726cf374846484ab43.jpg

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

5 hours ago, NotMyFault said:

Challenge: using 2 adjacent rectangles, is it possible to adjust the distance between both rectangles to get symmetrical colors of AA-edge pixels? In my tries, the colors of "touching" edge pixels never match.

Isn't that the way Antialiasing is meant to work? I guess it is theoretically possible to find a certain position for more even, symmetrical pixel colours. It depends on the angle of the curve edge + its position (division) on each pixel + "force pixel alignment".

I understand Antialiasing is a simulation to solve the problem of insufficient resolution: It needs to use more than 1 pixel to simulate fractions of pixels (for instance a triangular corner). See the top handle in your screenshot: it needs two pixels, a lighter and a darker pixel, whereas the lighter one is that of the handle position. The vector object edges go downwards through various pixels while the position of the curve determines the colour (brightness) of those pixels which build together the area which is touched by the curve. For each pixel the curve position on this pixel sets its colour, if the curve goes 'perfectly' diagonal through a pixel it results in a midtone, if the curve is more at the outer edge of a pixel then the pixel is darker etc.

So I assume a curve which goes diagonal through all pixels will result in even, symmetrical pixel colours, for instance:

2032847647_antialiasingsimulation.jpg.bc8a8f4d01689f7cb40516ae110c539e.jpg

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

8 hours ago, thomaso said:

Interesting. I think the pink is not an issue of Anti-Aliasing but rather of the LAB space, respectively the LAB model and its translation as interface with only three straight sliders.

Different to the HSL model where saturation and lightness are separate and each hue can have black / white

 

… the interface for the LAB model has black / white only for 1 certain 'hue' setting: A = 0 and B = 0:

 

See what happens if I increase L (lightness) of your Fill Layer from 30 to 100:

Another sample:    LAB blue tints.afpub
Tints of a LAB blue. Note in the Colours Panel the different colours in the slider (~white) versus the round colour well + applied colours (~cyan):
According to the LAB globe model I would expect the LAB slider for L = 100 would result in White colour, for every value of A and B.

 

Thanks thomaso, all true and known. 
My point is: even if what we get can be explained, Affinity does AA to achieve a certain visible result (and not to blindly do some math) If the current “formula” creates unexpected / wrong results, the formula should be adjusted to achieve correct results. Or deactivate AA when it goes wrong. Or documented as “known limitation”.

Actually, when doing this experiment in RGB or CMYK, rasterize the result, convert to LAB, you get the expected colors in LAB. So it is absolutely possible.

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.

My posts focus on technical aspects and leave out most of social grease like „maybe“, „in my opinion“, „I might be wrong“ etc. just add copy/paste all these softeners from this signature to make reading more comfortable for you. Otherwise I’m a fine person which respects you and everyone and wants to be respected.

 

Link to comment
Share on other sites

3 hours ago, thomaso said:

Isn't that the way Antialiasing is meant to work? I guess it is theoretically possible to find a certain position for more even, symmetrical pixel colours. It depends on the angle of the curve edge + its position (division) on each pixel + "force pixel alignment".

I understand Antialiasing is a simulation to solve the problem of insufficient resolution: It needs to use more than 1 pixel to simulate fractions of pixels (for instance a triangular corner). See the top handle in your screenshot: it needs two pixels, a lighter and a darker pixel, whereas the lighter one is that of the handle position. The vector object edges go downwards through various pixels while the position of the curve determines the colour (brightness) of those pixels which build together the area which is touched by the curve. For each pixel the curve position on this pixel sets its colour, if the curve goes 'perfectly' diagonal through a pixel it results in a midtone, if the curve is more at the outer edge of a pixel then the pixel is darker etc.

So I assume a curve which goes diagonal through all pixels will result in even, symmetrical pixel colours, for instance:

2032847647_antialiasingsimulation.jpg.bc8a8f4d01689f7cb40516ae110c539e.jpg

In your sample using 45 degree, AA creates only one additional color.

My question is more general: is it possible to get matching colors in every case (any angle)?
I assume there is no way, and I try to find the reasoning for that observation.

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.

My posts focus on technical aspects and leave out most of social grease like „maybe“, „in my opinion“, „I might be wrong“ etc. just add copy/paste all these softeners from this signature to make reading more comfortable for you. Otherwise I’m a fine person which respects you and everyone and wants to be respected.

 

Link to comment
Share on other sites

10 hours ago, NotMyFault said:

If the current “formula” creates unexpected / wrong results, the formula should be adjusted to achieve correct results.

I still assume your pink antialiased edges are caused by the LAB model and how it gets used in the interface. See below what increasing L (lightness) does to the dark fully saturated blue: Different than expected (+ previewed in the Tint slider) it does not go to White but to 'Cyan', which would mean it does not increase L but turns from the a to the b value (both -128 in this example). Then note that pink/magenta is in the other direction from this starting blue.

635531098_LABtint_expectedvsresult.jpg.ccecdbb0673fda3773bd89b901212632.jpg

 

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

10 hours ago, NotMyFault said:

My question is more general: is it possible to get matching colors in every case (any angle)?

Yes. Make sure you have Force Off set for the layer's Antialiasing. Use a stroke of the same (or different) colour as the fill but have the stroke at 50% (or other) transparency.

Mac Pro (Late 2013) Mac OS 12.7.6 
Affinity Designer 2.5.5 | Affinity Photo 2.5.5 | Affinity Publisher 2.5.5 | Beta versions as they appear.

I have never mastered color management, period, so I cannot help with that.

Link to comment
Share on other sites

20 hours ago, NotMyFault said:

Question (possible bug): having a document in lab mode, blue background, white rotated rectangle above, the AA-edge gets into pink colours. I would expect blue colours with increasing share of white, but no hue shift.

I dont think this is related with anti-aliasing (AA).

If you draw a 45 degree rectangle and if this passes diagonally through the middle of a pixel, as expected, we will have a pixel with 50% opacity.

ret.jpg.58f132586548208684596b3a56a74dbe.jpg

But, we must not forget that we have a background color. Therefore, there must be some blendig between the 50% opacity pixel and the background.

retback.jpg.83439cd521843bb04d79b4d31aed99a1.jpg

If, instead of a 45 degree rectangle, we add a 50% opacity layer, we should get the same result.

pixllay.jpg.7ae92b8513f4a3a84ea8617c6c8e9483.jpg

Like expected, we got te same result.

@NotMyFault, in your example, I have to admit that the same procedure in RGB produces a more realistic result. But will it always be like this? I haven't tested it, but I suspect that there are situations where the Lab produces a better transparency blend.

Link to comment
Share on other sites

10 hours ago, NotMyFault said:

In your sample using 45 degree, AA creates only one additional color.

My question is more general: is it possible to get matching colors in every case (any angle)?
I assume there is no way, and I try to find the reasoning for that observation.

I don't know the answer but again I assume it is caused by the way how Antialiasing works / gets calculated. In the clip below the upper curves are in angle 45º, and more than 1 color is involved for antialiasing pixels. See what a slow object move does to the antialising pixels, even with a purely horizontal movement there are moments where very light but additional pixels occur on its top (~ 0:22 min).

Also note that the reduced stroke width from 100 to 50 px + unchanged curve lengths results in only 1 pixel in stroke colour + 6 lighter 'antialising' pixels.

https://forum.affinity.serif.com/index.php?/topic/164176-anti-aliasing-question-and-challenge/# (0:40 min)

So I guess one can achieve identical pixels in two identical edges but the perfectly identical positions in fractions of pixels seems to matter here.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

Link to comment
Share on other sites

3 minutes ago, Lisbon said:

But, we must not forget that we have a background color. Therefore, there must be some blendig between the 50% opacity pixel and the background.

(...)

Like expected, we got te same result.

Your mixed green is hardly the same or a similar result than the pink in @NotMyFault's example. As I understand the OP it is the pinkish tint which confuses there, since pink is neither the colour of a light background blue nor of the white rectangles. – This is what makes me think it is caused by the LAB interface which seems to result for L = 100 in white only if a and b are = 0.

macOS 10.14.6 | MacBookPro Retina 15" | Eizo 27" | Affinity V1

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.