> No, POV-Ray writes the image pixel by pixel and line by line to file so no
> data is lost in a ten day render when your computer crashes in the mean
time
> and for memory conservation problems.  In order to do what you suggest,
> POV-Ray would need to store the whole image in memory in the unclipped
form.
> That requires at least 12 bytes per pixel (single precision floating-point
> rgb values), so rendering at i.e. 1280*1024 would require 15 MB alone!
>

1) This is not what I meant as Rune has pointed out.  The pixel obviously
gets clipped when POV writes it. My intention was why not clip it
proportional to itself rather than absolutely.

> This group is for discussing beta bug reports because the time is past for
> feature requests and you are asked to keep the off topic chatter down to
an
> absolute minimum.  Not getting a response in another group is no good
> justification for posting here.  Please read about the purpose of this
group
> in the welcome message (the first message in this group, dated Sept 4th)
or
> see the web archive of this group:

2) It is only a feature request and if it is the intended function. I can't
find anywhere in the docs where it is stated that this is the case nor can I
find a disclaimer stating that using values >1 could lead to unexpected
results.  If not a bug-report, than at least it should be clarified in the
docs.

3) I wouldn't have posted here if I didn't think it was justified, I have
seen a lot of other off-topic chatter here that didn't garner the same
response.  I have been testing 3.5 beta since it came out and have tried to
adhere to the posting guidelines for this group. My original query in the
other groups was to find out if it was intended or not so I wouldn't be
posting here without reason.

-tgq

Post a reply to this message

In article <3c079f21@news.povray.org> , "Trevor Quayle" 
<Tin### [at] hotmailcom> wrote:

> 2) It is only a feature request and if it is the intended function. I can't
> find anywhere in the docs where it is stated that this is the case nor can I
> find a disclaimer stating that using values >1 could lead to unexpected
> results.  If not a bug-report, than at least it should be clarified in the
> docs.

Well, as it worked this way every since there has been POV-Ray, how can it
be a bug?  Simply trying it out in 3.1 or earlier could have answered the
question.  And you surely have used 3.1 before so you know it worked its way
there.

Apart from that, nowhere in your original post you suggest it is a bug, and
no matter how often I read it, even between the lines I can't find a bug
report in there.  Your post doesn't sound very "polished" either, which it
should have been if you had seriously discussed it before elsewhere.  Of
course explaining complex ideas can be difficult, but trying to think about
them more would be a good idea.

> 1) This is not what I meant as Rune has pointed out.  The pixel obviously
> gets clipped when POV writes it. My intention was why not clip it
> proportional to itself rather than absolutely.

I see.  Indeed, this would not require to store the whole image.  However,
as it hasn't been needed in 15 years and I don't remember a patch for it or
any suggestion for such a patch.  I really wonder why it would be an feature
so important it has to be added to 3.5 (so to post here), if it would be a
worthwhile feature in the first place is yet another question, but I don't
want to get into a discussion about new features at all...

> 3) I wouldn't have posted here if I didn't think it was justified, I have
> seen a lot of other off-topic chatter here that didn't garner the same
> response.

Few people created off-topic threads, most of the time it developed
throughout a thread.  Saying you post here because "I've discussed color
clipping in the other groups before but never really got a clear answer on
what I really wanted to know" surely doesn't sound a justification to me,
only like a way to force some answer, which you got.

As for my reminder, it was not personal and wasn't written this way either,
it was a reminder about the rules we have set up in these groups and try to
hold up.  That occasionally this doesn't work is hardly a justification for
ignoring the rules :-)

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> Well, as it worked this way every since there has
> been POV-Ray, how can it be a bug?

Why do some people keep saying that? Just because something worked the same
way in POV-Ray 3.1, it doesn't mean it can't be a bug. In fact POV-Ray 3.1
has some quite serious bugs, such as the normal bug.

> However, as it hasn't been needed in 15 years

That's not for any individual to say. Maybe *you* didn't need it...

> I really wonder why it would be an feature so important
> it has to be added to 3.5 (so to post here)

Well, here I agree. It's not that important... But he may have a point that
it maybe should be mentioned in the docs.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In article <3c07b5e6@news.povray.org> , "Rune" <run### [at] mobilixnetdk>
wrote:

>> Well, as it worked this way every since there has
>> been POV-Ray, how can it be a bug?
>
> Why do some people keep saying that? Just because something worked the same
> way in POV-Ray 3.1, it doesn't mean it can't be a bug. In fact POV-Ray 3.1
> has some quite serious bugs, such as the normal bug.

I said it works this way "every since there has been POV-Ray", ***not***
that it always worked this way only in POV-Ray 3.1.  How about actually
reading what I say before picking on it???

>> However, as it hasn't been needed in 15 years
>
> That's not for any individual to say. Maybe *you* didn't need it...

Please don't take half of my sentence away and then put words in my mouth.
I said "However, as it hasn't been needed in 15 years and I don't remember a
patch for it or any suggestion for such a patch." and it is quite obvious
what I mean if you read the sentence and maybe the whole paragraph to the
*end*.

>> I really wonder why it would be an feature so important
>> it has to be added to 3.5 (so to post here)
>
> Well, here I agree. It's not that important... But he may have a point that
> it maybe should be mentioned in the docs.

Actually, I think the docs mention that the colors are clipped somewhere.  I
have to admit I don't know where from memory and I don't have time to look
right now...

    Thorsten

Post a reply to this message

> Actually, I think the docs mention that the colors are clipped somewhere.
I
> have to admit I don't know where from memory and I don't have time to look
> right now...

As I stated, I searched and cannot find it.  I realized what was going on by
accident from some previous thread in one of the other groups.

-tgq

Post a reply to this message

In article <3c07c015$1@news.povray.org> , "Trevor Quayle" 
<Tin### [at] hotmailcom> wrote:

>> Actually, I think the docs mention that the colors are clipped somewhere.
> I
>> have to admit I don't know where from memory and I don't have time to look
>> right now...
>
> As I stated, I searched and cannot find it.  I realized what was going on by
> accident from some previous thread in one of the other groups.

I think if it really isn't anywhere in the docs, it should be added.

    Thorsten

____________________________________________________
Thorsten Froehlich, Duisburg, Germany
e-mail: tho### [at] trfde

Visit POV-Ray on the web: http://mac.povray.org

Post a reply to this message

"Thorsten Froehlich" wrote:
> I said it works this way "every since there has
> been POV-Ray", ***not*** that it always worked
> this way only in POV-Ray 3.1.  How about actually
> reading what I say before picking on it???

Not all users have versions of POV-Ray installed prior to version 3.1. And
you said "Simply trying it out in 3.1 ***or*** earlier could have answered
the question." I find that you implied that trying it out in POV-Ray 3.1
would be enough to find out if it was a bug. Demanding the user to test it
in earlier versions than that would be unfair anyway IMO.

> Please don't take half of my sentence away and
> then put words in my mouth.

I find the rest of the sentence irrelevant. I think most POV-Ray users are
not active in the POV-Ray society at all. But I agree that the fact that
there hasn't been a patch or much discussion indicates that the need has not
been particularly strong among most users.

Rune
--
3D images and anims, include files, tutorials and more:
Rune's World:    http://rsj.mobilixnet.dk (updated Nov 5)
POV-Ray Users:   http://rsj.mobilixnet.dk/povrayusers/
POV-Ray Webring: http://webring.povray.co.uk

Post a reply to this message

In my personal opinion, the current behaviour is the correct one.
  What a color with component values greater than 1 does is to oversaturate
the image. Oversaturation usually means that it gets white (unless it's a
pure color, eg. pure red or pure yellow).
  This is what happens with, for example, the sun. The light emitted by the
sun is not pure white, but it's so bright that it oversaturates it is seen
as white.

-- 
#macro N(D,I)#if(I<6)cylinder{M()#local D[I]=div(D[I],104);M().5,2pigment{
rgb M()}}N(D,(D[I]>99?I:I+1))#end#end#macro M()<mod(D[I],13)-6,mod(div(D[I
],13),8)-3,10>#end blob{N(array[6]{11117333955,
7382340,3358,3900569407,970,4254934330},0)}//                     - Warp -

Post a reply to this message

Trevor,


I agree with Warp that the values should be clipped at 1, but there
should be some way for a completely red object to saturate to white if
it is bright enough.  Right now, a color will only saturate to white if
none of its color components are zero.


I have experimented with this a bit, and it seems to me that POV could
simulate saturation of bright light sources better.


What should be done?  Well, the "red sensors" in your eye and on film or
in a video camera (or etc.) are also a little bit sensitive to green and
slightly sensitive to blue.  To simulate this, the rendered colors could
be modified by

red_out   = min( red         + green/256 + blue/256/256 , 1.0);
green_out = min( red/256     + green     + blue/256     , 1.0);
blue_out  = min( red/256/256 + green/256 + blue         , 1.0);

in POV's "color clip" function.


This would not break 24-bit images with ordinary light sources, and
would not have any significant computational cost.


- Ben

Post a reply to this message

in news:3c07c20b@news.povray.org Thorsten Froehlich wrote:

> I think if it really isn't anywhere in the docs, it should be added.
> 
> 

I'll do so.

Ingo

-- 
Photography: http://members.home.nl/ingoogni/
Pov-Ray    : http://members.home.nl/seed7/

Post a reply to this message