Continuing with the A* pathfinding project,

(AND perhaps the srgb - rgb thread)

I have an image that I generate by color-filling M$ Excel cells, and
copy-pasting that into IrfanView, and saving to .png

I then want to look at certain colors to determine if it's a walkable path, or
an obstacle.

This works well when I specify colors with all 255's or all 0's, but when I have
intermediate shades, I'm trying to use the <0-255, 0-255, 0-255>/255 value as a
comparison, but the algorithm is just recognizing it all as unwalkable.

I'll probably have to go back on run some tests to see what eval_pigment returns
as an rgb triplet.
I'm wondering if I'm going to have to have to use srgb.
I also was thinking about specifying a narrow _range_ of values to give me a
+/-1 wiggle room in byte values when converted to 0-1, so that'll probably
involve math.inc and a special use of VEq and a threshold.

Has anyone ever come across a situation like this?





I currently have enough worked out where I can randomly place 100 people in the
building and sequentially solve the "maze" to generate a shortest exit-path for
all 100 people.  I'm skipping over 5 pixels of the map at every step to generate
a much smaller "graph" to search, but it still takes about 5 min.

- BE

Post a reply to this message

On 28/04/2024 15:15, Bald Eagle wrote:

> I have an image that I generate by color-filling M$ Excel cells, and
> copy-pasting that into IrfanView, and saving to .png
> 
> I then want to look at certain colors to determine if it's a walkable path, or
> an obstacle.
> 
> This works well when I specify colors with all 255's or all 0's, but when I have
> intermediate shades, I'm trying to use the <0-255, 0-255, 0-255>/255 value as a
> comparison, but the algorithm is just recognizing it all as unwalkable.
> 
> I'll probably have to go back on run some tests to see what eval_pigment returns
> as an rgb triplet.
> I'm wondering if I'm going to have to have to use srgb.
> I also was thinking about specifying a narrow _range_ of values to give me a
> +/-1 wiggle room in byte values when converted to 0-1, so that'll probably
> involve math.inc and a special use of VEq and a threshold.
> 
> Has anyone ever come across a situation like this?

Not sure i understand your problem, but yes, eval_pigment does return a
color triplet <red, green, blue> in [0..1] range.

An idea for your comparisons: turn your color into HSV.
- Compare the wanted color with the H value plus/minus intervale (degrees).
- Reject colors that are below a threshold of S and V.



IMHO about srgb (and the current discussion in p.b.tutorials) :
This model is useful for calculating the final pixel color value as a
function of object pigment, light and gamma. But not the other way around...




-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

kurtz le pirate <kur### [at] gmailcom> wrote:

> Not sure i understand your problem, but yes, eval_pigment does return a
> color triplet <red, green, blue> in [0..1] range.

So I fill cells in Excel, copy-paste them into IrfanView to make an image file,
and then POV-Ray looks at those pixels with eval_pigment.

When I'm looking for specific colors to determine if something is floor, wall,
door, etc, it's easy to use the 255 or 0 values and just divide by 255.

When I try it with that last peach color, using if(EvalPigmentColor =
ExcelByteColor/255), it doesn't work.


> An idea for your comparisons: turn your color into HSV.
> - Compare the wanted color with the H value plus/minus intervale (degrees).
> - Reject colors that are below a threshold of S and V.

It's an unwanted extra layer, but a good idea - I think the clarity of doing the
HSV way would simplify things.

Hopefully I'll have some time to try it all out tonight.

Thanks!

- BW

Post a reply to this message

Attachments:
Download 'excel rgb colors.png' (11 KB)

Preview of image 'excel rgb colors.png'

On 2024-05-01 10:05 (-4), Bald Eagle wrote:
> 
> So I fill cells in Excel, copy-paste them into IrfanView to make an image file,
> and then POV-Ray looks at those pixels with eval_pigment.
> 
> When I'm looking for specific colors to determine if something is floor, wall,
> door, etc, it's easy to use the 255 or 0 values and just divide by 255.
> 
> When I try it with that last peach color, using if(EvalPigmentColor =
> ExcelByteColor/255), it doesn't work.

I can tell from that last peach color that there is no sRGB conversion
going on.  <248, 203, 173> is the literal byte value of the swatch
encoded as sRGB, and <0.97, 0.8, 0.68> is straight division by 255.  In
POV-Ray, srgb <248, 203, 173> / 255 should give you the same value as
eval_pigment(), which I predict will be rgb <0.939, 0.597, 0.418>.  Try:

#local Tmp = srgb ExcelByteColor/255;
if(EvalPigmentColor = Tmp)

POV-Ray does not provide conversion back to sRGB, but if you need that,
I have some tools at https://github.com/CousinRicky/RC3-POV-Tools

Post a reply to this message

On 01/05/2024 16:05, Bald Eagle wrote:

> When I try it with that last peach color, using if(EvalPigmentColor =
> ExcelByteColor/255), it doesn't work.

ok, ok, I understand better the problem.

I quickly coded a test. The result (of little interest) is attached, but
I think the problem lies in the precision/tolerance of the calculations.


I defined the pigment like this (but you know this) :

#declare pigmentSize = 5;
#declare myPigment = pigment {
 image_map {
  png "excel rgb colors"
  map_type 0
  interpolate 2
  }
 scale pigmentSize
 }


The purpose of the test is to give a greater height for pixels whose
color is peach. Several tries and it didn't work.



I created this macro, which compares the source color with the chosen
color, introducing a "tolerance" variable :

#macro CheckColor(thisCol, targetCol, tol)
 ((abs(thisCol.red*255-targetCol.red)<=tol) &
  (abs(thisCol.green*255-targetCol.green)<=tol) &
  (abs(thisCol.blue*255-targetCol.blue)<=tol) )
#end


Two variables:
#declare TargetColor = rgb <248, 203, 173>; // peach color
#declare Tolerance = 16; // this parameter is very very sensitive



In the image constitution, I retrieve the color of the source image:
 #declare myRGB = eval_pigment(myPigment, <xIndex, zIndex, 0>);


If the color is close to the one defined, I make a higher box:
 box {
  <2*xIndex-steep, 0, 2*zIndex-steep>, <2*xIndex + steep,
0.05*(CheckColor(myRGB, TargetColor ,Tolerance)?10:1), 2*zIndex + steep>
 pigment { color myRGB }
 }



This is where the value of the tolerance variable is important !
With value lower than 16 (about 6%) here, there's no higher box.
The code looks bad :(


This "large" tolerance value causes artifacts to appear elsewhere in the
image.



Maybe it's the wrong way...
Can any of this help you?



-- 
Kurtz le pirate
Compagnie de la Banquise

Post a reply to this message

Attachments:
Download 'be.png' (163 KB)

Preview of image 'be.png'

kurtz le pirate <kur### [at] gmailcom> wrote:

> I quickly coded a test. The result (of little interest) is attached, but
> I think the problem lies in the precision/tolerance of the calculations.

Yes, that's what I was thinking as well.


> I created this macro, which compares the source color with the chosen
> color, introducing a "tolerance" variable :

That's indeed the kind of thing I was looking for.

> If the color is close to the one defined, I make a higher box:

So you are definitely recognizing the peach color separately from the other
colors.

I'm wondering what it would look like if you took Ricky's advice and expressed
the eval_pigment results as both rgb and srgb-converted values and used those
for your comparison, and output the results to the #debug stream.

(And I still like your HSV idea - I definitely think it's more intuitive and
versatile for how I'll be using color coded information)

- BW

Post a reply to this message

When I was playing with palettes this is  what I use to gather the colors

#declare Imagemap=pigment{image_map{tga "EarthTopography.tga" gamma 1}}
#declare FnA = function {pigment {Imagemap scale<Imagewidth,Imageheight,1>}}

   a&b are integers 0<= a <Imagewidth 0<= b <Imageheight
    #declare FV=FnA(a,b,1);
    #declare C1=int(FV.x*255+.5);//red
    #declare C2=int(FV.y*255+.5);//green
    #declare C3=int(FV.z*255+.5);//blue

 These integers was used to sort colors into a 256 element palette.


  You may notice that I scale the image function very large and that I rounded
up the fraction that the function returned.

Hope this helps.

Have Fun!

Post a reply to this message