AD 2.1 Why can not select same fill color with Vector Flood Fill Tool?

[nasu wong]

I'm on Window10.

[Hangman]

This is working as expected on macOS... could you perhaps upload your Designer file so we can take a look at it. There's nothing immediately obvious that would prevent Select Same Fill Colour from working...

[lepr]

@nasu wong

I think I have an explanation for you.

The colour sampler gets an RGB colour when used in the view of an RGB document, regardless of the mode of the Colour panel, because it samples from an RGB composite image, not the individual objects in the document. 

For example, say the blue fill of a source object has an HSL definition. The colour sampler will get an RGB colour from the document view rather than the HSL colour of the object. When that RGB blue is assigned to the fill of another vector object, that object's fill will not be considered the same as the source object's fill, despite the blues looking identical, because one fill will be RGB and the other HSL.

 

[nasu wong]

@Hangman Thank you.

SLsame.afdesign

[lepr]

@nasu wong I don't know why you chose to completely ignore me, but your SLsame document is as I expected, objects initially with HSL fills. I explained why you aren't getting new fills to be considered the same despite looking the same.

[carl123]

8 hours ago, ,,, said:

For example, say the blue fill of a source object has an HSL definition. The colour sampler will get an RGB colour from the document view rather than the HSL colour

So, how can you see the HSL colour values to show they are different?

[lepr]

9 minutes ago, carl123 said:

So, how can you see the HSL colour values to show they are different?

Ensure no object is selected. Set the Colour panel to sliders mode and unlock the padlock. Now when you select an object, you get its actual fill/stroke definition in the Colour panel.

(Be careful with the padlock unlocked: changing the sliders colour model (for example, from RGB to CMYK) when an object is selected will actually change the object's fill/stroke definition to the new colour model of the sliders.)

[nasu wong]

 ''' I'm sorry about that. I send a new VDO and affinity file. Notice if I forgot to fill a cat ear and turn back to do it. It still not to select same fill color to add into a single layer. 

 

 

Thank you very much.

 

 

SLsame01.afdesign

[Chris B]

We do have an open issue where the HSL of a picked colour can differ from an objects original HSL values. This looks like that. I'll get them linked and update the report.

[lepr]

5 hours ago, nasu wong said:

I send a new VDO and affinity file. Notice if I forgot to fill a cat ear and turn back to do it. It still not to select same fill color to add into a single layer.

Hi, thanks for the cat document with RGB-filled objects instead of HSL-filled objects. I carefully repeated your procedure several times and each time the Select Same Fill did select all the expected objects. I'm afraid I cannot explain why that works correctly for me and not for you, but I am using 2.1.0.1732 on macOS, whereas you are using Windows software.

[lepr]

5 hours ago, Chris B said:

We do have an open issue where the HSL of a picked colour can differ from an objects original HSL values. This looks like that. I'll get them linked and update the report.

Sorry to disagree, but that's not the issue here and I hope a developer reads this thread rather than just a second-hand account of it.

I explained why the OP was having a problem with their first RGB document which has HSL fills, and its not what you seem to be suggesting it might be, and now the OP has a problem with their second RGB document which has no HSL fills.

The mystery now is what is causing a problem for the OP with their second RGB document that involves RGB only and no HSL, especially since I'm not suffering their problem with that document on my Mac.

 

[Hangman]

Hi @nasu wong

As @Chris B mentioned, the issue is caused by a known bug where the RGB and by association, HSL (which is an alternative representation of the RGB colour model) picked colours can differ from the objects' original RGB/HSL values.

The issue only affects RGB/HSL colour values and works correctly for CMYK, LAB and Greyscale colour when using their respective document colour format...

 

There only two colours, the grey and yellow, from the RGB cat graphic where Select Same works. These are the two colours where the picked source colour correctly matches the destination colour. The other four colours (Pink, Purple, Blue and Teal) show different source and destination colour values hence Select Same doesn't recognise them as the same colour...

For the CMYK, LAB and Greyscale graphics, the source and destination colours match resulting in Select Same correctly matching and selecting the respective colours.

Note: When using mixed document and colour formats, e.g., A CMYK document with RGB colour values or vice versa the destination colour value applied when using the colour picker is specified using the same colour format as the document itself rather than the colour format of the selected object which results in no colour matches when using Select Same for obvious reasons.

[nasu wong]

@Hangman My last test about your 

Note: When using mixed document and colour formats, e.g., A CMYK document with RGB colour values or vice versa the destination colour value applied when using the colour picker is specified using the same colour format as the document itself rather than the colour format of the selected object which results in no colour matches when using Select Same for obvious reasons.

 

[Hangman]

@nasu wong

Part of the issue in your last screen recording is, as @,,, mentioned above, you have the Lock Colourspace Padlock enabled (i.e., locked) so changing your document Colour Format doesn't automatically change the colour format of your graphics, i.e., changing the document colour format to CMYK doesn't change the fact that your graphics are defined using RGB values...

Going back to your first cat video, on Mac the values used for the orange colour on the face and ears are the same hence Select Same works as expected, but I suspect on Windows it's different but the blue value used for the whiskers is different on Mac as well and just as on Windows Select Same doesn't work because of the different values...

One thing to note is that simply changing the colour palette between different colour models is enough to trigger this issue, e.g., changing from RGB to HSL doesn't translate colours completley accurately...

Unfortunately, if changing between colour models the solution is to re-enter the colour values for each element again prior to using the colour picker or vector flood fill tool to correct the discrepancies introduced...

[lepr]

17 minutes ago, Hangman said:

Part of the issue in your last screen recording is, as @,,, mentioned above, you have the Lock Colourspace Padlock enabled (i.e., locked) so changing your document Colour Format doesn't automatically change the colour format of your graphics, i.e., changing the document colour format to CMYK doesn't change the fact that your graphics are defined using RGB values...

I did mention the Colour panel padlock, but I certainly never said that it has an influence over colour definitions not changing when the document colour model is changed.

Changing a document's colour model will not change the definition of fills, regardless of the padlock status. An RGB fill will remain an RGB fill, a HSL fill will remain a HSL fill, a CMYK fill will remain a CMYK fill, etc, when a document's colour model is changed. The Colour panel's padlock status has no influence over that persistence.

The padlock status does affect the colour model with which the Colour panel presents a fill, and the padlock status does affect whether or not a fill's colour model is changed when the panel's colour model is changed.

[Hangman]

4 minutes ago, ,,, said:

I did mention the Colour panel padlock, but I certainly never said that it has an influence over colour definitions not changing when the document colour model is changed.

The reference was simply to the Lock Colourspace padlock, I'm wasn't quoting you in the remainder of that sentence...

7 minutes ago, ,,, said:

Changing a document's colour model will not change the definition of fills, regardless of the padlock status. An RGB fill will remain an RGB fill, a HSL fill will remain a HSL fill, a CMYK fill will remain a CMYK fill, etc, when a document's colour model is changed. The Colour panel's padlock status has no influence over that persistence.

As mentioned in the previous post...

11 minutes ago, ,,, said:

The padlock status does affect the colour model with which the Colour panel presents a fill, and the padlock status does affect whether or not a fill's colour model is changed when the panel's colour model is changed.

Exactly...

[lepr]

5 minutes ago, Hangman said:

The reference was simply to the Lock Colourspace padlock, I'm wasn't quoting you in the remainder of that sentence...

The extent to which you were referencing me was ambiguous, and so I wanted to make clear that I did not state the erroneous part of your message.

[lepr]

@nasu wong

I've taken a closer look at your cat document SLsame01.afdesign.

The document posted is RGBA/8 and has RGB fills, but the fills have greater than 8-bit precision and most of the fill values do not have exact 8-bit equivalents. That suggests the fills have been converted to RGB/8 from some other format.

When I sample one of your source objects in the document view with the colour picker, the returned colour (from the view's raster composite image) has only 8-bit precision, and so an object filled with that returned colour will not be considered as having the same fill as your source object despite looking identical and having the same numeric values presented in the colour panel when the panel is showing 8-bit values.

With the colour panel set to display 16-bit RGB values, the discrepancy between source object fill and sampled colour becomes clear. The sampled colour values, being 8-bit, are always a multiple of 257 when 16-bit values are shown, whereas your source object fills have many values that are not multiples of 257.

Addition: should have stated that the only fills in that 8-bit document which are precisely representable in 8-bit format are the grey of the face and white of the eyes, and so these are the only ones which will be considered the same as another fill created from a colour collected by a colour picker.

Edited April 1, 2023 by ,,,
addition