Is there a way to do this in pov-ray (fopen maybe?), or will I need to  
write a program for it?

I was just thinking this would be pretty sweet for sampling in colors from  
a real world object/texture/scene for use in pov..especially if the colors  
are ordered in some way.

-- 
Ian McDonald
Lean Agile .NET 4.0/MVC
Senior Application Architect,
Developer and Security Analyst

Post a reply to this message

[GDS|Entropy] <gdsHYentropyAThotmailDTcom> wrote:
> Is there a way to do this in pov-ray (fopen maybe?), or will I need to  
> write a program for it?

  Do what?

-- 
                                                          - Warp

Post a reply to this message

Greetings,

Le 29/12/2010 09:30, Warp nous fit lire :
> [GDS|Entropy] <gdsHYentropyAThotmailDTcom> wrote:
>> Is there a way to do this in pov-ray (fopen maybe?), or will I need to  
>> write a program for it?
> 
>   Do what?
> 
As usual with neo-posters, they put their query in the title and
continue in the body (lame). (neo-neo-posters use SMS-style text too)

It seems that GDS want to access color(s) from image.
May be to put them in a color_map.

At least 3 issues:
 * even a gif is converted in a memory image without map (from index to
rgb values)
 * pixels are lost (sort of), the image is <0,0> to <1,1>
 * fopen is to be used with text file, not most image's formats: binary.

The function eval_pigment(pigment,vector) from functions.inc can be used
to sample the image_map (that's a pigment) at various places.

In fact, it might be wise to look at its definition.

Recovering all the colours from an image file, especially the unused map
entries: no.
Ordering the colours: DIY.

Post a reply to this message

Am 29.12.2010 09:58, schrieb Le_Forgeron:

> At least 3 issues:
>   * even a gif is converted in a memory image without map (from index to
> rgb values)

Not strictly correct; to save memory, GIF images are stored internally 
as paletted images, too. You're right however insofar as you can't 
access the palette directly.

>   * pixels are lost (sort of), the image is<0,0>  to<1,1>

In POV-Ray 3.7, you can use the min_extent/max_extent function on an 
image_map to get its true dimensions; if you don't use interpolation 
this allows you to loop over all the pixels.

>   * fopen is to be used with text file, not most image's formats: binary.

In POV-Ray 3.7, binary access is supported. However, I wouldn't 
recommend this approach except for very simple image formats.

An alternative would be the PPM format, which comes in a flavor that is 
essentially a plain text table of integers in blank-separated value format.

Post a reply to this message

On Wed, 29 Dec 2010 03:58:55 -0500, Le_Forgeron <jgr### [at] freefr> wrote:

> Greetings,
>
> Le 29/12/2010 09:30, Warp nous fit lire :
>> [GDS|Entropy] <gdsHYentropyAThotmailDTcom> wrote:
>>> Is there a way to do this in pov-ray (fopen maybe?), or will I need to
>>> write a program for it?
>>
>>   Do what?
>>
> As usual with neo-posters, they put their query in the title and
> continue in the body (lame). (neo-neo-posters use SMS-style text too)

That wasn't very nice.
Perhaps you would like to search the server for my name; you will find I  
am not any sort of "neo-poster". I see no need for redundancy, hence the  
question in the title.

> It seems that GDS want to access color(s) from image.
> May be to put them in a color_map.
>
> At least 3 issues:
>  * even a gif is converted in a memory image without map (from index to
> rgb values)
>  * pixels are lost (sort of), the image is <0,0> to <1,1>
>  * fopen is to be used with text file, not most image's formats: binary.
>
> The function eval_pigment(pigment,vector) from functions.inc can be used
> to sample the image_map (that's a pigment) at various places.
>
> In fact, it might be wise to look at its definition.
>
> Recovering all the colours from an image file, especially the unused map
> entries: no.
> Ordering the colours: DIY.

I will just write a program to do this then.

-- 
Ian McDonald
Lean Agile .NET 4.0/MVC
Senior Application Architect,
Developer and Security Analyst

Post a reply to this message

[GDS|Entropy] <gdsHYentropyAThotmailDTcom> wrote:
> Perhaps you would like to search the server for my name; you will find I  
> am not any sort of "neo-poster". I see no need for redundancy, hence the  
> question in the title.

  It has been part of the usenet etiquette for forever that you don't put
your question in the title of your post. The body of your post should be
understandable even without the title.

-- 
                                                          - Warp

Post a reply to this message

On 12/30/2010 03:26 AM, Warp wrote:
> [GDS|Entropy] <gdsHYentropyAThotmailDTcom> wrote:
>> Perhaps you would like to search the server for my name; you will find I  
>> am not any sort of "neo-poster". I see no need for redundancy, hence the  
>> question in the title.
> 
>   It has been part of the usenet etiquette for forever that you don't put
> your question in the title of your post. The body of your post should be
> understandable even without the title.
> 
i love it when you guys pick nits .... slow day eh?

Post a reply to this message

Le_Forgeron <jgr### [at] freefr> wrote:

>
> The function eval_pigment(pigment,vector) from functions.inc can be used
> to sample the image_map (that's a pigment) at various places.

and Clipka wrote:
> In POV-Ray 3.7, you can use the min_extent/max_extent function on an
> image_map to get its true dimensions; if you don't use interpolation
> this allows you to loop over all the pixels.

I was thinking along the same lines. If the OP wanted to sample all the colors
in the *entire* image, I guess he would need to set up a nested #while loop
scheme, and step (carefully!) pixel by pixel...in x and y, I'm assuming (the
default orientation for an image_map.)

When using eval_pigment on such an image, oriented in the default plane, does
the z-position matter? In other words, is the image considered 'infinite' in z?

Ken

Post a reply to this message

Am 31.12.2010 08:19, schrieb Kenneth:

> When using eval_pigment on such an image, oriented in the default plane, does
> the z-position matter? In other words, is the image considered 'infinite' in z?

Yes, the manual tells the truth about this ;-)

Post a reply to this message

clipka <ano### [at] anonymousorg> wrote:
> Am 31.12.2010 08:19, schrieb Kenneth:
>
> > When using eval_pigment on such an image, oriented in the default plane, does
> > the z-position matter? In other words, is the image considered 'infinite' in z?
>
> Yes, the manual tells the truth about this ;-)

Ah, so it does. (1.1.5.1 in the Wiki, "Specifying an Image_Map".)  Somehow I
should have remembered this. :-[

I guess it's a good thing to re-read the manual...every now and then...  :-P

Post a reply to this message