I want to use a specific palette to make it strictly index color.

[ken]

Sorry, but could you please tell me?

I want to create a palette called blue using the colors used in an image and then change to indexed color mode based on that palette information, but I'm having trouble.

For example, if there are two colors in a custom palette,

Color A (R100 G100 B100) and Color B (R100 G100 B101),

the color will be automatically converted to one of them.

The following settings should also be fine.

- No dithering
- Uncheck Dither transparent areas

Is there a way to convert the color information in the custom palette without tampering with it?

[Ofnuts]

In the palettes list, you can import a palette from an image, and when converting an image to color indexed, you can specify a color palette.

Quote:Is there a way to convert the color information in the custom palette without tampering with it?

What do you call "convert"? Or do you want to map your image to another palette using the same color indices?

[ken]

Thank you for your quick reply.
By "converting" I mean converting to an indexed color image using a custom palette I created.

As shown in the attached image, I created a 255-type color palette and performed the indexed color conversion, but some colors are automatically replaced with similar colors, resulting in an indexed color image.
I would like it to be converted to the colors registered in the custom palette without being automatically replaced.

If you know how to solve this please let me know. Thank you in advance.

[Ofnuts]

(12-17-2024, 01:15 PM)ken Wrote: Thank you for your quick reply.
By "converting" I mean converting to an indexed color image using a custom palette I created.

As shown in the attached image, I created a 255-type color palette and performed the indexed color conversion, but some colors are automatically replaced with similar colors, resulting in an indexed color image.
I would like it to be converted to the colors registered in the custom palette without being automatically replaced.

If you know how to solve this please let me know. Thank you in advance.

I don't understand what you want, these two things seem incompatible:

• to be converted to the colors registered in the custom palette
  
• without being automatically replaced
  

So, what should happen?

Also: "and performed the indexed color conversion, but some colors are automatically replaced with similar colors, resulting in an indexed color image" implies that getting an indexed color image isn't the result that you expect from the conversion to indexed color, which doesn't really make sense.

[ken]

Sorry for my poor explanation

I will explain further with pictures.

If you have the RGB image on the left,
and convert it to an index color image,
you want it to be like image A, but for some reason it becomes image B.

This seems to happen when the colors are similar, but is there anything that can be done about this phenomenon?

[Ofnuts]

Two explanations:

1. There is a bug, in which case you can report it (but with the actual image and palette)
   
2. Your expectation of "closest color" is not the same as Gimp's. This wouldn't be surprising since looking at the comments in the source code (see here around line 31) Gimp  doesn't match colors in RGB but in CIE L*a*b space (and the comment at line 22 hints that in Gimp3 this will be done using the linear and not gamma-encoded values).
   

[ken]

(12-18-2024, 09:43 AM)Ofnuts Wrote: Two explanations:

1. There is a bug, in which case you can report it (but with the actual image and palette)
   
2. Your expectation of "closest color" is not the same as Gimp's. This wouldn't be surprising since looking at the comments in the source code (see here around line 31) Gimp  doesn't match colors in RGB but in CIE L*a*b space (and the comment at line 22 hints that in Gimp3  this will be done using the linear and not gamma-encoded values).
   

I think this is a bug, so I would like it to be fixed.

By the way, I am using LinuxMint and Windows11
and the same issue occurs on Gimp 2.10 and 3.0.0RC1.

Here is the image that actually had the problem.

How can I add palette information (gpl)?

[Ofnuts]

(12-18-2024, 11:08 AM)ken Wrote:

(12-18-2024, 09:43 AM)Ofnuts Wrote: Two explanations:

1. There is a bug, in which case you can report it (but with the actual image and palette)
   
2. Your expectation of "closest color" is not the same as Gimp's. This wouldn't be surprising since looking at the comments in the source code (see here around line 31) Gimp  doesn't match colors in RGB but in CIE L*a*b space (and the comment at line 22 hints that in Gimp3  this will be done using the linear and not gamma-encoded values).
   

I think this is a bug, so I would like it to be fixed.

By the way, I am using LinuxMint and Windows11
and the same issue occurs on Gimp 2.10 and 3.0.0RC1.

Here is the image that actually had the problem.

How can I add palette information (gpl)?

You can put the GPL in a ZIP and attach it here. But as far as I can see you don't even need a palette to show the problem:

•  Color > Info > Color cube analysis shows 229 distinct colors in the image, so that 's less than 256 and you can use these to make a palette for color-indexing
  
• Importing a palette from the image indeed yields a 229-colors palette
  
• You can convert your image to indexed using this new palette. You would expect the conversion to be perfect....
  
• If you copy-paste the color-indexed image back over the original image and compare them (top in "difference" mode) you indeed find that there are pixels that are different, the worst offender being pixels with color (0,0,64) being indexed to the color (0,0,60).
  
• Problem appears worse in 2.10 than in 3.0
  
• Just reported here.
  
  
  
  
  
  
  
  

[ken]

(12-18-2024, 09:46 PM)Ofnuts Wrote:

(12-18-2024, 11:08 AM)ken Wrote:

(12-18-2024, 09:43 AM)Ofnuts Wrote: Two explanations:

1. There is a bug, in which case you can report it (but with the actual image and palette)
   
2. Your expectation of "closest color" is not the same as Gimp's. This wouldn't be surprising since looking at the comments in the source code (see here around line 31) Gimp  doesn't match colors in RGB but in CIE L*a*b space (and the comment at line 22 hints that in Gimp3  this will be done using the linear and not gamma-encoded values).
   

I think this is a bug, so I would like it to be fixed.

By the way, I am using LinuxMint and Windows11
and the same issue occurs on Gimp 2.10 and 3.0.0RC1.

Here is the image that actually had the problem.

How can I add palette information (gpl)?

You can put the GPL in a ZIP and attach it here. But as far as I can see you don't even need a palette to show the problem:

•  Color > Info > Color cube analysis shows 229 distinct colors in the image, so that 's less than 256 and you can use these to make a palette for color-indexing
  
• Importing a palette from the image indeed yields a 229-colors palette
  
• You can convert your image to indexed using this new palette. You would expect the conversion to be perfect....
  
• If you copy-paste the color-indexed image back over the original image and compare them (top in "difference" mode) you indeed find that there are pixels that are different, the worst offender being pixels with color (0,0,64) being indexed to the color (0,0,60).
  
• Problem appears worse in 2.10 than in 3.0
  
• Just reported here.
  
  
  Thank you for looking into this issue.
  For now, I guess I'll have to wait for a Gimp update to fix this issue.
  I hope it will be fixed in the official version of 3.0.
  
  
  
  
  

[rich2005]

Just a note, not sure what is / was required. You can of course get a palette from the image. Not in the order of the image, I wonder where that swatch came from ? You can sort a palette by color / luminosity .. but if you want something in the same order as the swatch image, then maybe some tedious hand editing  That is a 16x16 grid, I did the top line, not going to do the remainder.