Thorsten Froehlich <tho### [at] trfde> wrote:
> Get over it and fix your scenes!

  This is an incorrect solution.

  Have you ever heard of film exposure times and overexposures?
Overexposure is not always a mistake in photography, nor is it in
raytracing either.

  Here's an example of intentional overexposure in a photograph:
http://www.students.tut.fi/~warp/photos/patikka2/35.jpg
  If the shutter speed of the camera would have been set so that the
brightest part of the image (in this case the Sun) would have the
maximum intensity the camera could measure, then everything in the
photograph except the Sun would be almost completely black. Letting
the Sun overexpose the photograph was completely intentional and
in fact gives a good photographical effect.

  The photo also gives a hint about the truely correct solution to
the problem.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Eli <eli### [at] jehoelnet> wrote:
> I hardly use the built-in antialiasing. I use the focal blur trick instead, 
> although it doesn't work if the aperture is too small. 

  What is "the focal blur trick"?

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

Post a reply to this message

Rafal 'Raf256' Maj <spa### [at] raf256com> wrote:
> Imho this *is* the correct behaviour in most cases

  Not in photography. Neither solution is physically correct.

> if only *10 times 
> brighter object occupies 1/10 (or more) of pixel - enitre pixel should be 
> white.

  But what happens if an object which occupies an entire pixel is 10 times
brighter than what the pixel can represent?

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

war### [at] tagpovrayorg news:4132edfb@news.povray.org

>   But what happens if an object which occupies an entire pixel is 10
>   times 
> brighter than what the pixel can represent?

If he eye is not accomodated - it will only represent the maximum value.

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

In article <4132ed5f@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   Here's an example of intentional overexposure in a photograph:
> http://www.students.tut.fi/~warp/photos/patikka2/35.jpg
>   If the shutter speed of the camera would have been set so that the
> brightest part of the image (in this case the Sun) would have the
> maximum intensity the camera could measure, then everything in the
> photograph except the Sun would be almost completely black. Letting
> the Sun overexpose the photograph was completely intentional and
> in fact gives a good photographical effect.
>
>   The photo also gives a hint about the truely correct solution to
> the problem.

Indeed.  And the correct solution can only be implemented if the
anti-aliasing occurs prior to clipping colors.

    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

Warp wrote:

>   Have you ever heard of film exposure times and overexposures?
> Overexposure is not always a mistake in photography, nor is it in
> raytracing either.

Slightly OT, but:

In my opinion "overexposure" or "underexposure" is allways a mistake and 
not intentional. "Increasing exposure" or "decreasing exposure", on the 
other hand, IS intentional and gives the desired result and the result 
is then a correctly exposed image. And all this relates allways to the 
usage of a light meter which gives some initial values for shutter speed 
and aperture that we can alter.

In your image, it is hard to say whether it is overexposed or 
underexposed or both/neither. The scene itself (expect the sun) is maybe 
underexposed as there is no detail in the trees. The sun is overexposed 
because it is very bright. The whole scene is probably quite correctly 
exposed to give desired effect. With small P&S digital cameras it is 
quite common that deepest shadows are "blocked" (ie. black, no detail) 
and brightest highlights are "blown out" (white, no detail). With good 
B&W film it is possible to capture a wider dynamic range with some detail.

> Letting the Sun overexpose the photograph was completely intentional 
> and in fact gives a good photographical effect.

Actually sun is not "overexposing the photograph" but sun "gets 
overexposed in the photograph".


Severi

Post a reply to this message

Severi Salminen <sev### [at] not_thissibafi> wrote:
> Actually sun is not "overexposing the photograph" but sun "gets 
> overexposed in the photograph".

  Whatever... :P

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

Post a reply to this message

Rafal 'Raf256' Maj <spa### [at] raf256com> wrote:
> >   But what happens if an object which occupies an entire pixel is 10
> >   times 
> > brighter than what the pixel can represent?

> If he eye is not accomodated - it will only represent the maximum value.

  It will appear larger than it really is, even in the human eye (and
specially in a photograph).

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Indeed.  And the correct solution can only be implemented if the
> anti-aliasing occurs prior to clipping colors.

  The problem is that when there's overexposure, the "antialias
before clipping" gets only half-way to the solution and thus what you
are seeing is the result of an algorithm which is incomplete and shows
artifacts as a result.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

war### [at] tagpovrayorg news:41332a06@news.povray.org

>   It will appear larger than it really is, even in the human eye (and
> specially in a photograph).
> 

So that's a task for post-processing.

I even write such a progam :) It needs input as 2 images (one normal, and 
second much darker - to compress input, but array of floats would also be 
good), and it can add some small lens-flare-like reflections etc.



-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

"Rafal 'Raf256' Maj" <spa### [at] raf256com> wrote in message
news:Xns9555A63CFFB51raf256com@203.29.75.35...
> war### [at] tagpovrayorg news:41332a06@news.povray.org
>
> >   It will appear larger than it really is, even in the human eye (and
> > specially in a photograph).
> >
>
> So that's a task for post-processing.

Why post-processing ?  Can't the 'bleeding' be computed while tracing ? When a
pixel is brighter than can be represented, just add some of that color to the
surrounding pixels.  Won't this solve the AA-problem?

Or am I talking nonsense here? :)

cu!
--
camera{location-z*3}#macro G(b,e)b+(e-b)*(C/50)#end#macro L(b,e,k,l)#local C=0
;#while(C<50)sphere{G(b,e),.1pigment{rgb G(k,l)}finish{ambient 1}}#local C=C+1
;#end#end L(y-x,y,x,x+y)L(y,-x-y,x+y,y)L(-x-y,-y,y,y+z)L(-y,y,y+z,x+y)L(0,x+y,
<.5,1,.5>,x)L(0,x-y,<.5,1,.5>,x)               // ZK http://www.povplace.be.tf

Post a reply to this message

Zeger Knaepen <zeg### [at] studentkuleuvenacbe> wrote:
> Why post-processing ?  Can't the 'bleeding' be computed while tracing ? When a
> pixel is brighter than can be represented, just add some of that color to the
> surrounding pixels.  Won't this solve the AA-problem?

  It will probably require changing the way POV-Ray handles the rendered
image. It would need to be able to change previously traced pixels (which
currently might already have been saved to the destination file) and
pixels yet to be traced.

-- 
plane{-x+y,-1pigment{bozo color_map{[0rgb x][1rgb x+y]}turbulence 1}}
sphere{0,2pigment{rgbt 1}interior{media{emission 1density{spherical
density_map{[0rgb 0][.5rgb<1,.5>][1rgb 1]}turbulence.9}}}scale
<1,1,3>hollow}text{ttf"timrom""Warp".1,0translate<-1,-.1,2>}//  - Warp -

Post a reply to this message

Warp wrote:

> Thorsten Froehlich <tho### [at] trfde> wrote:
> 
>>Get over it and fix your scenes!
> 
> 
>   This is an incorrect solution.
> 
>   Have you ever heard of film exposure times and overexposures?
> Overexposure is not always a mistake in photography, nor is it in
> raytracing either.
> 
>   Here's an example of intentional overexposure in a photograph:
> http://www.students.tut.fi/~warp/photos/patikka2/35.jpg
>   If the shutter speed of the camera would have been set so that the
> brightest part of the image (in this case the Sun) would have the
> maximum intensity the camera could measure, then everything in the
> photograph except the Sun would be almost completely black. Letting
> the Sun overexpose the photograph was completely intentional and
> in fact gives a good photographical effect.
> 
>   The photo also gives a hint about the truely correct solution to
> the problem.

I suspect that the colour bleeding around the sun
in this photo is caused by inperfections in the
camera lens.

One has "correct exposure" when the film has the
desired densities for certain object(s)/area(s).

Many automatic exposure systems tries to achieve a
certain density on the film for objects with
"medium tones".

-- 
Tor Olav
http://subcube.net
http://subcube.com

Post a reply to this message

war### [at] tagpovrayorg news:4133696d@news.povray.org

>   It will probably require changing the way POV-Ray handles the rendered
> image. It would need to be able to change previously traced pixels (which
> currently might already have been saved to the destination file) and
> pixels yet to be traced.
> 

So IMHo adding post-processing would be very useffull.

Perhaps I could provide an patch (that maybe later would be included in 
MegaPOV then Pov Official)

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

Tor Olav Kristensen <tor### [at] toberemovedhotmailcom> wrote:
> I suspect that the colour bleeding around the sun
> in this photo is caused by inperfections in the
> camera lens.

  No, it's a property of the film (well, in this case the CCD of the
digital camera, but it works the same way there). Sometimes when you
have extreme overexposure at the border of a frame in a film, the
brightness might even bleed partially to the adjacent frame.

  Without this natural property it would be impossible to photograph
things which are smaller than what the film would normally record, no
matter how bright these things are. However, as we know, if the thing
is bright enough, it will imprint the film no matter how small it is.

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

Post a reply to this message

In article <4133a71f$1@news.povray.org> , Tor Olav Kristensen 
<tor### [at] TOBEREMOVEDhotmailcom>  wrote:

> I suspect that the colour bleeding around the sun
> in this photo is caused by inperfections in the
> camera lens.

Not necessarily  keep in mind that film also is not infinitely thin.  For
color film the depth light has to penetrate to reach all three layers is
about three times the films resolution.  And the light scatters in each
layer as well.  This creates a natural blur effect at sharp light/dark
transitions.  I.e. <http://mac.povray.org/rhein.jpg> is (a after two JPEG
compressions) scan of a positive film and the resolution in the image is
about 80 lines per millimeter*.  Looking at the two bell towers clearly
shows a kind of blur. But, the sunlight entered at about a 30 degree angle,
so even without refraction it did pass at least two pixels.  Add scattering
and you get exactly the blur effect seen.

> One has "correct exposure" when the film has the
> desired densities for certain object(s)/area(s).

Yes, but keep in mind that film also has a very high dynamic range (for film
in the dark regions) compared to a digital display.  I.e. the image linked
above was edited to correct for the bad display dynamic range to make the
dark areas visible approximately as they are to the human eye.

> Many automatic exposure systems tries to achieve a
> certain density on the film for objects with
> "medium tones".

I think this is what most people come to expect nowadays due to point and
shot cameras.  It is only natural to expect the same for computer generated
images.

    Thorsten

* About half the scanner resolution - the image was scaled down before.
Film resolution for the film that was used is 135 lines per millimeter
according to manufacturer at 1000:1 contrast ratio.

____________________________________________________
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

Warp wrote:


>   No, it's a property of the film (well, in this case the CCD of the
> digital camera, but it works the same way there). Sometimes when you
> have extreme overexposure at the border of a frame in a film, the
> brightness might even bleed partially to the adjacent frame.
> 
>   Without this natural property it would be impossible to photograph
> things which are smaller than what the film would normally record, no
> matter how bright these things are. However, as we know, if the thing
> is bright enough, it will imprint the film no matter how small it is.

Actually it is imperfections both in the lens and in the film/sensor. 
Even the best lenses have many different aberrations (like spherical 
aberration, chromatic aberration etc.) which cause a point in the scene 
render a circle/disc/ellipse/whatever to the film. Also the film is not 
perfect: there are many layers in the film. These cause inner 
reflections which spread the light that hits the film.

Question is: should POV-Ray try to simulate an imperfect optical system? 
And is antialiasing the right place to do it?

Post a reply to this message

In article <41342dd8@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>  No, it's a property of the film (well, in this case the CCD of the
> digital camera, but it works the same way there).

Actually, with a CCD you get many problem in case of overexposure.  The CCD
elements have a charge limit.  And you get charge transfers to neighboring
pixels in the same line.

Even worse, all but the most expensive CCDs depend on a filter grid and the
camera later interpolating to get the final resolution image (the CCD
resolution quoted for digital cameras is always that of a monochrome
CCD!!!).  As color samples are distributed in a gird getting a good
approximation very close to the CCD resolution works, but it also adds a
slight blur, which later comes in very handy when having to use JPEG
compression, which is more effective with a certain level of blur.

> Sometimes when you
> have extreme overexposure at the border of a frame in a film, the
> brightness might even bleed partially to the adjacent frame.

Which is an effect of scattering inside the camera...

    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

In article <4133696d@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   It will probably require changing the way POV-Ray handles the rendered
> image. It would need to be able to change previously traced pixels (which
> currently might already have been saved to the destination file) and
> pixels yet to be traced.

Nope, just trace a few (four perhaps) more pixels one pixel off in each
direction.  Would be slower, yes, but also simulate film more accurately.

    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

Severi Salminen <sev### [at] not_thissibafi> wrote:
> Question is: should POV-Ray try to simulate an imperfect optical system? 

  POV-Ray is already doing that.
  Antialiasing brings the image closer to what a photograph would look like.
Why stop half-way?

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

Post a reply to this message

Thorsten Froehlich <tho### [at] trfde> wrote:
> Nope, just trace a few (four perhaps) more pixels one pixel off in each
> direction.  Would be slower, yes, but also simulate film more accurately.

  That would be like a kind of blur which scales the samples taken from
outside the current pixel so that only very bright samples will have a
visible effect in the current pixel?

  However, that would not be enough. The brighter the object, the larger
the color bleed. You can't achieve that with just four extra rays. And
even if you used more rays, you would just get graininess, which is not
a nice artifact.

  A simple 2D processing of the pixels would get a nice result fast and
without artifacts, and will probably not look almost at all different
from a raytraced version where you send a million rays around the current
pixel.

-- 
#macro M(A,N,D,L)plane{-z,-9pigment{mandel L*9translate N color_map{[0rgb x]
[1rgb 9]}scale<D,D*3D>*1e3}rotate y*A*8}#end M(-3<1.206434.28623>70,7)M(
-1<.7438.1795>1,20)M(1<.77595.13699>30,20)M(3<.75923.07145>80,99)// - Warp -

Post a reply to this message

Warp wrote:

> Severi Salminen <sev### [at] not_thissibafi> wrote:
> 
>>Question is: should POV-Ray try to simulate an imperfect optical system? 
> 
> 
>   POV-Ray is already doing that.
>   Antialiasing brings the image closer to what a photograph would look like.
> Why stop half-way?
Because everything in the current implementation can be performed on
a pixel by pixel base, without changing already computed pixels or
influencing things to come. Some solutions would require that
or require postprocessing. Adding a new switch to get old
behaviour begs the question on where that switch should be.
Do we want that on an object by object base or as a global switch.
Some solutions require a rather big extension to the SDL.
Perhaps adding a pointspread function is easiest to implement
because it is close to focal blur, perhaps not. I will let
the POV team decide.

My suggestion would be to wait a couple of weeks and see what
the POV team comes up with. They said that they were working
on it (or at least discussing), so there is no need anymore
for a discussion if a solution would be desirable.

Post a reply to this message

Thorsten Froehlich wrote:

> In article <4133a71f$1@news.povray.org> , Tor Olav Kristensen 
> <tor### [at] TOBEREMOVEDhotmailcom>  wrote:
> 
> 
>>I suspect that the colour bleeding around the sun
>>in this photo is caused by inperfections in the
>>camera lens.
> 
> 
> Not necessarily  keep in mind that film also is not infinitely thin.  For
> color film the depth light has to penetrate to reach all three layers is
> about three times the films resolution.  And the light scatters in each
> layer as well.  This creates a natural blur effect at sharp light/dark
> transitions.  I.e. <http://mac.povray.org/rhein.jpg> is (a after two JPEG
> compressions) scan of a positive film and the resolution in the image is
> about 80 lines per millimeter*.  Looking at the two bell towers clearly
> shows a kind of blur. But, the sunlight entered at about a 30 degree angle,
> so even without refraction it did pass at least two pixels.  Add scattering
> and you get exactly the blur effect seen.
...

The sun covers about 0.5 degrees of our field of view:

http://www.google.com/search?q=2*atan%28radius+of+Sun%2FAstronomical+Unit%29+radians+in+degrees


A camera with 35mm film (36 mm x 24 mm) and a normal lens (50mm)
will have a field of view of about 40 degrees:

http://www.google.com/search?q=2*atan%2836%2F%282*50%29%29+radians+in+degrees


Now I assume that the CCD (or film) in the camera that shot the
picture that Warp gave a link to, covers the whole field of view
of the lens. I also assume that the image was shot with a 50 mm
lens and that the image has not been cropped.

http://www.students.tut.fi/~warp/photos/patikka2/35.jpg
(That image is 1136 pixels x 856 pixles.)

If these assumtions are correct, then the image has
1136 pixels / 40 degrees = 28 pixels/degree

This means that if there were no distortions in the atmosphere,
inside lens or inside the film, then the sun would cover about
28 pixels/degree * 0.5 degrees = 14 pixels.
(See http://home.online.no/~t-o-k/35_Sun.jpg)


The colour bleeding in the image extends somewhere between 77
pixels and 296 pixels from the center of the sun.
(See http://home.online.no/~t-o-k/35_Bleeding.jpg)

If we can agree that the colour bleeding in the image is more
than 200 pixels from the center of the sun, then it will follow
that the radius of the colour bleeding on the film is more than

200 pixels / 1136 pixels * 36 mm = 6.3 mm


I measured a piece of 35 mm film to be about 0.14 mm thick.

6.3 mm / 0.14 mm = 45.3

Now I cannot make myself believe that the internal scattering/
refraction/reflections in the layers of a such a film will
extend as far as 45 times the thickness of the film.

-- 
Tor Olav
http://subcube.net
http://subcube.com

Post a reply to this message

In article <4134b858$1@news.povray.org> , Tor Olav Kristensen 
<tor### [at] TOBEREMOVEDhotmailcom>  wrote:

> A camera with 35mm film (36 mm x 24 mm) and a normal lens (50mm)
> will have a field of view of about 40 degrees:
>
> http://www.google.com/search?q=2*atan%2836%2F%282*50%29%29+radians+in+degrees
>
>
> Now I assume that the CCD (or film) in the camera that shot the
> picture that Warp gave a link to, covers the whole field of view
> of the lens.

This is (unless it is a really expensive pro digital camera that you can get
a small new car for) incorrect as CCDs are 1/2" or 3/4", which is much
smaller than film.  This is why you get a tele effect if you use an
inexpensive digital camera with the same lens you used for a film camera.

> I also assume that the image was shot with a 50 mm
> lens and that the image has not been cropped.

A lot of assumptions, aren't this?

> I measured a piece of 35 mm film to be about 0.14 mm thick.

Yes, this pretty much cuts it.

> 6.3 mm / 0.14 mm = 45.3
>
> Now I cannot make myself believe that the internal scattering/
> refraction/reflections in the layers of a such a film will
> extend as far as 45 times the thickness of the film.

Indeed, when overexposing with an extremely bright object like the sun it is
very likely other effects than film scattering will play an important role.
Certainly the lens, but also the atmosphere and even the camera interior
will scatter a real lot of sunlight.

    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

In article <41346449@news.povray.org> , Warp <war### [at] tagpovrayorg>  wrote:

>   However, that would not be enough. The brighter the object, the larger
> the color bleed. You can't achieve that with just four extra rays.

Certainly not, but you can determine is there is anything very bright
nearby. This would be sufficient to solve the AA, without adding perfectly
realistic color bleeding of course.

    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

tho### [at] trfde news:4134c67b@news.povray.org

> Certainly not, but you can determine is there is anything very bright
> nearby. This would be sufficient to solve the AA, without adding
> perfectly realistic color bleeding of course.

But I agree with Warp - postprocessing is only reasonable solutions, since 
other solutions will work severa time slower - because of recalculating 
previously rendered points several time, with is total waste of time IMHO

-- 
http://www.raf256.com/3d/
Rafal Maj 'Raf256', home page - http://www.raf256.com/me/
Computer Graphics

Post a reply to this message

> (unless it is a really expensive pro digital camera that you can get
> a small new car for)

	You mean e.g. the C*n*n 1Ds ?  ;-)

> This is why you get a tele effect if you use an
> inexpensive digital camera with the same lens you used for a film camera.

	Be careful, purists would tell you this is not a "tele" effect
but simply a "crop" effect, as you don't change the caracteristics of
the lens by reducing the captor size.

	- NC

Post a reply to this message

In article <4134daec$1@news.povray.org> , Nicolas Calimet 
<pov### [at] freefr>  wrote:

>> (unless it is a really expensive pro digital camera that you can get
>> a small new car for)
>
>  You mean e.g. the C*n*n 1Ds ?  ;-)

Except that it also only has a single CCD with 28.7 x 19.1 mm size.

>> This is why you get a tele effect if you use an
>> inexpensive digital camera with the same lens you used for a film camera.
>
>  Be careful, purists would tell you this is not a "tele" effect
> but simply a "crop" effect, as you don't change the caracteristics of
> the lens by reducing the captor size.

For the D1 it is called "Lens focal length conversion factor".  I guess this
is the marketing term for: "Engineering told management that a full-size CCD
sensor would be much more expensive".  Fact is that as with all ICs, for
CCDs the production error also increases with die size.  hence CCDs with
36*24 mm are rather expensive, but there are a few available these days
afaik.

    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

> Except that it also only has a single CCD with 28.7 x 19.1 mm size.

	No, two mistakes here: the 1Ds is a full-frame 11 Mpix CMOS sensor  :-)
	{And I believe its manufacturor will release soon an update that will
make it become a 16 Mpix sensor; wild guess based on the release of the recent
20D consumer camera, and by the last 5-years development strategy of the
company}.

> For the D1 it is called "Lens focal length conversion factor".

	It is called like this for all digital cameras, although that's much
more useful for DSLRs I admit (consumer as well as prosumer markets).

> hence CCDs with
> 36*24 mm are rather expensive, but there are a few available these days
> afaik.

	The only full-size CCD I know of is in the K*d*ck DCS 14n (14 Mpix).
Larger CCDs are found in non 24x36 formats (don't know the appropriate term
in english) mostly used in studio for packshot-like productions, or maybe
landscapes.  As these cost much more than the price of a small new car  ;-)

	- NC

Post a reply to this message

In article <4134ee55@news.povray.org> , Nicolas Calimet <pov### [at] freefr>
wrote:

>  No, two mistakes here: the 1Ds is a full-frame 11 Mpix CMOS sensor  :-)

Not according to the Canon website:
<http://www.usa.canon.com/EOS-1D/specs.html>

I suppose I am missing something here, but I cannot figure out what :-(

    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

On Tue, 31 Aug 2004 23:45:53 +0200, Thorsten Froehlich <tho### [at] trfde>  
wrote:
> In article <4134ee55@news.povray.org> , Nicolas Calimet  
> <pov### [at] freefr>
> wrote:
>>  No, two mistakes here: the 1Ds is a full-frame 11 Mpix CMOS sensor  :-)
>
> Not according to the Canon website:
> <http://www.usa.canon.com/EOS-1D/specs.html>
>
> I suppose I am missing something here, but I cannot figure out what :-(


These two have CMOS sensors:

EOS-1Ds:
http://consumer.usa.canon.com/ir/controller?act=ModelDetailAct&fcategoryid=139&modelid=8280

EOS-1D Mark II Digital:
http://consumer.usa.canon.com/ir/controller?act=ModelDetailAct&fcategoryid=139&modelid=9808

The first one (EOS-1Ds) is the one Nicolas mentioned.



-- 
FE

Post a reply to this message

> <http://www.usa.canon.com/EOS-1D/specs.html>

	The 1D is about 3 years old now, and has been recently updated
by the "1D mark II" which is a 8 Mpix CMOS with x1.3 crop factor (i.e
it's sensor size is halfway from consumer-level x1.5/x1.6 cameras
and the 1Ds/DCS14n).

1DmkII: http://www.dpreview.com/reviews/canoneos1dmkii/page2.asp
1Ds: http://www.dpreview.com/reviews/canoneos1ds/page2.asp

	About the DCS14n mentionned previously, in fact it also uses
a CMOS and not a CCD, as specified here (didn't check the official
website as they don't always give so much detailed specs):

http://www.dpreview.com/reviews/kodakdcs14n/page2.asp

	That's probably because a full-size CCD would be too expensive
even for pros using a 24x36 camera.

	- NC

Post a reply to this message

Thorsten Froehlich" <tho### [at] trfde> wrote ...
>
> It is not like somebody in the team woke up one day and said: Hey, what am
I
> going to do today?  Ah, yes, I know, I am going to "break" anti-aliasing
to
> screw up Rune's scenes.
>
> It is a clear correction to previously incorrect behavior.  Previously
> POV-Ray was broken, it no longer is.
>

I realize I'm jumping into this conversation very late, but...

I have to disagree.  I think the previous behavior was actually correct and
the new behavior is incorrect.

Let me explain why:

As I understand it, anti-aliasing is intended to simulate the effect of
downsampling an image rendered at a higher resolution.  The whole point of
AA is to remove the "aliasing" jaggies.  That is its sole purpose.

So, if you were to perform AA by hand by rendering the image at a higher
resolution and then downsample it using an external paint program, the
downsampling is clearly occurring after clipping and gamma correction.  As
such, POV should simulate this behavior.  I am confident that this was done
on purpose and not by accident

So, my "proof" goes like this:
1)  AA is intended to simulate downsampling of a rendered image
2)  Downsampling of a rendered image is performed after clipping and gamma
correction
Conclusion:  AA should be performed after clipping and gamma correction

The important observation here is that, IMHO, anti-aliasing was NEVER
intended to simulate anything that happens in a camera.  It was intended to
simulate something that happens in a 2D paint program.

-Nathan Kopp

Post a reply to this message

About the order of anti-aliasing and gamma correction:

Nathan Kopp wrote:
> So, if you were to perform AA by hand by rendering the image at a higher
> resolution and then downsample it using an external paint program, the
> downsampling is clearly occurring after clipping and gamma correction.

Yes, but if the program does it properly (I suspect most don't), it goes 
like this: undo the gamma encoding to get linear sample values, process 
these, and re-gamma-encode them. So the effect is the same as if the 
downsampling was done before the gamma correction (apart from some 
rounding errors).


About the order of anti-aliasing and clipping: I tend to agree with Rune 
and Slime (and Nathan) on this matter, and I don't have anything to add 
to the discussion.

  -Christian

Post a reply to this message

> 2)  Downsampling of a rendered image is performed after clipping and gamma
> correction
> Conclusion:  AA should be performed after clipping and gamma correction

You should read my post in this thread made at 8/27/04 4:19 PM about gamma
correction.

 - Slime
 [ http://www.slimeland.com/ ]

Post a reply to this message

Rune wrote:

> Christoph Hormann wrote:
> 
>>The effect you get with antialiasing in POV-Ray 3.6.1 is like
>>rendering in high resolution to a HDR image and scaling it down.
> 
> 
> So do that when the user has selected HDR image as output, but not when the
> user has selected one of the common "old" formats limited to the 0-1 range.
> 
Is it possible to have HDR output with 3.6 ? I couldn't find anything 
about this in the doc...
Because given HDR output, the problem could be solved by post-processing 
it, for example simulating somehow the bleeding of bright area, etc...
This is not necessarily the task of the raytracer, and could be 
impplemented in a separate program.

As I understand it, the whole problem here seems to be that some 
consider antialiasing as a kind of post-process aimed at removing 
jaggies in the image, while other think of it as an integration method 
that has no sense on clipped values...

-- 
Vincent

Post a reply to this message

On Fri, 03 Sep 2004 11:25:06 +0200, Vincent LE CHEVALIER  
<lec### [at] ctiecpfr> wrote:
> Is it possible to have HDR output with 3.6 ? I couldn't find anything  
> about this in the doc...
> Because given HDR output, the problem could be solved by post-processing  
> it, for example simulating somehow the bleeding of bright area, etc...
> This is not necessarily the task of the raytracer, and could be  
> impplemented in a separate program.
>
> As I understand it, the whole problem here seems to be that some  
> consider antialiasing as a kind of post-process aimed at removing  
> jaggies in the image, while other think of it as an integration method  
> that has no sense on clipped values...


I'm currently working on a patch to have HDRI input/output in POV-Ray  
using OpenEXR and possibly also Radiance HDR. The actual input/output  
routines are done, but getting unclipped output is more hassle than it's  
worth in 3.6.0, and the 3.6.1 source for Windows has not yet been  
released. I'm not changing any Windows-specific files though, so I might  
try merging the Linux source.
I am also considering some kind of support for exposure control, but I  
don't have anything solid in that area yet.



-- 
FE

Post a reply to this message

On Fri, 03 Sep 2004 11:42:35 +0200, Fredrik Eriksson <noo### [at] nowherecom>  
wrote:
> I'm currently working on a patch to have HDRI input/output in POV-Ray  
> using OpenEXR and possibly also Radiance HDR. The actual input/output  
> routines are done, but getting unclipped output is more hassle than it's  
> worth in 3.6.0, and the 3.6.1 source for Windows has not yet been  
> released. I'm not changing any Windows-specific files though, so I might  
> try merging the Linux source.
> I am also considering some kind of support for exposure control, but I  
> don't have anything solid in that area yet.


Status update:

Copying everything but the front-end code from the Unix source package  
worked just fine. I now have a version of POV-Ray that can both read and  
write HDRI data in OpenEXR format, and which outputs an unclipped image  
when a HDRI output format is chosen.


I now have a few questions for the POV community:

- Is support for 32-bits per component floating point output desired?
It wouldn't take much effort to do, but I doubt it's needed/useful.

- Is support for the Radiance HDR format desired?
It's a trivial thing to add, so unless the answer is a resounding no, it  
will most likely be done.

- What kind of functionality is desired regarding exposure control, and  
how would you like to see it done?
I have a few vague ideas, but I have yet to investigate their feasibility.

- What kind of support applications are desired?
Currently I have only a small program that can convert between OpenEXR and  
Radiance HDR, but I'm considering doing something a little bigger that  
would let you do some limited processing (e.g. exposure control,  
downsampling) on OpenEXR images.



-- 
FE

Post a reply to this message

Vincent LE CHEVALIER wrote:
> 
> Is it possible to have HDR output with 3.6 ? I couldn't find anything 
> about this in the doc...

HDR output is supported in MegaPOV 1.1.


Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

Fredrik Eriksson wrote:
> 
> I now have a few questions for the POV community:
> 
> - Is support for 32-bits per component floating point output desired?
> It wouldn't take much effort to do, but I doubt it's needed/useful.

That would be great if you would implement it in a portable way (i.e. 
allowing exchange of files between different endiannesses and between 
IEEE and non-IEEE floating point systems.  This is possible but not trivial.

> - Is support for the Radiance HDR format desired?
> It's a trivial thing to add, so unless the answer is a resounding no, 
> it  will most likely be done.

This is already supported in MegaPOV 1.1.

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 03 Sep 2004 14:57:00 +0200, Christoph Hormann  
<chr### [at] gmxde> wrote:
> Fredrik Eriksson wrote:
>>  I now have a few questions for the POV community:
>>  - Is support for 32-bits per component floating point output desired?
>> It wouldn't take much effort to do, but I doubt it's needed/useful.
>
> That would be great if you would implement it in a portable way (i.e.  
> allowing exchange of files between different endiannesses and between  
> IEEE and non-IEEE floating point systems.  This is possible but not  
> trivial.


I'm using the OpenEXR library, so it's portable to any system that's  
portable to. If all I wanted was to output "raw" FP data, I could have  
used the code I posted in this forum on the 25th. I want the extra  
features of OpenEXR however.
Currently I'm using the 16-bit "half" output format, but OpenEXR supports  
32-bit float as well.

 From the OpenEXR website:
"OpenEXR has been ported to GNU/Linux, OS X 10.2, Win32, and IRIX. It  
should be fairly easy to port to other UNIX-like operating systems."


The header 'half.h' contains this text:

//	The implementation of type half makes the following assumptions
//	about the implementation of the built-in C++ types:
//
//	    float is an IEEE 754 single-precision number
//	    sizeof (float) == 4
//	    sizeof (unsigned int) == sizeof (float)
//	    alignof (unsigned int) == alignof (float)
//	    sizeof (unsigned short) == 2


I'm going to have a look to see if I can loosen those restrictions. I'll  
also try to see if there are any other restrictions, either implicit or  
stated elsewhere.
Hopefully, I'll be able to change those restrictions to something like:
- float has a range comparable to, or greater than, that of the IEEE-754  
single precision type
- sizeof( unsigned int ) >= 4
- sizeof( unsigned short ) >= 2




On a related note:
Does anyone have a (preferably complete) list of platforms to which  
POV-Ray has been successfully ported?
I am particularly interested in issues such as endianness (or, more  
generally, byte order), the size of primitive data types and alignment  
restrictions.



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
>>
>> That would be great if you would implement it in a portable way (i.e.  
>> allowing exchange of files between different endiannesses and between  
>> IEEE and non-IEEE floating point systems.  This is possible but not  
>> trivial.
> 
> I'm using the OpenEXR library, so it's portable to any system that's  
> portable to. If all I wanted was to output "raw" FP data, I could have  
> used the code I posted in this forum on the 25th. I want the extra  
> features of OpenEXR however.
> [...]

I am not talking about OpenEXR support (to me being required to download 
9MB to add support for a new file format is quite out of question).  I 
am talking about plain binary floating point data.  I stopped studying 
your code snippet when i read:

typedef unsigned long uint32;

> On a related note:
> Does anyone have a (preferably complete) list of platforms to which  
> POV-Ray has been successfully ported?

POV-Ray should compile on any platform where a C++ compiler is available 
that supports the current standards.  So for writing portable extensions 
for POV-Ray you should comply with the standard first of all (and if you 
do it will most likely also compile and run on most platforms.

And the typedef cited above is a serious affront to the standard...

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 03 Sep 2004 16:15:05 +0200, Christoph Hormann  
<chr### [at] gmxde> wrote:
> I am not talking about OpenEXR support (to me being required to download  
> 9MB to add support for a new file format is quite out of question).


How is this any different from having to download libjpeg, or libpng?



> I am talking about plain binary floating point data.
> I stopped studying your code snippet when i read:
>
> typedef unsigned long uint32;


If you had read further, you would have seen that the code actually checks  
to see if uint32 really does have the required range. That typedef was not  
supposed to be valid across all platforms; it was meant to be replaced  
with something else on platforms where the assumption does not hold.
The code I posted was not meant as production quality code; it was meant  
as a proof-of-concept. I didn't want to expend time and effort on writing  
the machinery required to select an appropriate type for all reasonable  
and unreasonable platforms when all I wanted was to show the feasibility  
of the implementation.

By the way: Is it possible to compile and run POV-Ray on a platform where  
'long' is less than 32 bits?



> POV-Ray should compile on any platform where a C++ compiler is available  
> that supports the current standards.  So for writing portable extensions  
> for POV-Ray you should comply with the standard first of all (and if you  
> do it will most likely also compile and run on most platforms.


Again: Is POV-Ray portable to platforms where 'long' is less than 32 bits?
For that matter, is POV-Ray portable to platforms where 'int' is less than  
32 bits?

Having seen the POV-Ray source code, I am confident that the answer is  
'no' to both questions.



> And the typedef cited above is a serious affront to the standard...


No, it has implementation-defined behaviour. Even that is irrelevant if  
the range is checked/enforced.



-- 
FE

Post a reply to this message

Fredrik Eriksson wrote:
> 
>> I am not talking about OpenEXR support (to me being required to 
>> download  9MB to add support for a new file format is quite out of 
>> question).
> 
> How is this any different from having to download libjpeg, or libpng?

Those libs are very small, so small that they are included in the 
POV-Ray distribution.  And they are much more widely tested.

Don't get me wrong - if support for a new format allows something not 
possible before that's good but i do not yet see this happening.  And 
even if it does the drawbacks are significant.

> 
> By the way: Is it possible to compile and run POV-Ray on a platform 
> where  'long' is less than 32 bits?

AFAIK the standard defines 'long' as at least 32 bit.

> 
>> And the typedef cited above is a serious affront to the standard...
> 
> No, it has implementation-defined behaviour. Even that is irrelevant if  
> the range is checked/enforced.

Then don't name it 'uint32' (which implies being 32 bit).

Christoph

-- 
POV-Ray tutorials, include files, Sim-POV,
HCR-Edit and more: http://www.tu-bs.de/~y0013390/
Last updated 06 Jul. 2004 _____./\/^>_*_<^\/\.______

Post a reply to this message

On Fri, 03 Sep 2004 17:58:31 +0200, Christoph Hormann  
<chr### [at] gmxde> wrote:
> Fredrik Eriksson wrote:
>>  How is this any different from having to download libjpeg, or libpng?
>
> Those libs are very small, so small that they are included in the  
> POV-Ray distribution.  And they are much more widely tested.


The parts that actually need to be included are only a little over 3 MB,  
on par with the tiff library included in the POV-Ray distribution. The  
archive you can download from the OpenEXR website contains a whole lot of  
other stuff not needed to compile the library.



> Don't get me wrong - if support for a new format allows something not  
> possible before that's good but i do not yet see this happening.  And  
> even if it does the drawbacks are significant.


What other significant drawbacks do you see, other than portability  
concerns?



>>  By the way: Is it possible to compile and run POV-Ray on a platform  
>> where  'long' is less than 32 bits?
>
> AFAIK the standard defines 'long' as at least 32 bit.


As far as *I* know, the standard does not. 'long' must be at least as big  
as 'int', which must be at least as big as 'short', which must be at least  
16 bits. 'int' must also be at least as big as 'char'.
Strictly speaking, the standard does not even guarantee that the  
fundamental types have sizes that are powers of two. Is POV-Ray portable  
to systems where CHAR_BIT == 9?



> Then don't name it 'uint32' (which implies being 32 bit).


Would it have been acceptable to you if I had named it  
'uint_at_least_32_bits'?



-- 
FE

Post a reply to this message

-----BEGIN PGP SIGNED MESSAGE-----
Hash: SHA1

Christoph Hormann wrote:
|>> And the typedef cited above is a serious affront to the standard...
|>
|>
|> No, it has implementation-defined behaviour. Even that is irrelevant
|> if  the range is checked/enforced.
|
|
| Then don't name it 'uint32' (which implies being 32 bit).
|
	You do know that the ISO-C99 standard defines uint32_t for an int
type that's guaranteed to be 32 bits, don't you? It's in the stdint.h
header (see:
http://www.dinkumware.com/manuals/reader.aspx?b=c/&h=stdint.html for
details)

		Jerome
- --
******************************
*      Jerome M. Berger      *
* mailto:jbe### [at] ifrancecom *
*  http://jeberger.free.fr/  *
******************************
-----BEGIN PGP SIGNATURE-----
Version: GnuPG v1.2.4 (GNU/Linux)

iD8DBQFBOM3aqIYJdJhyixIRAuAzAKCGyd6LHl39FcR96J3iy+BnN6qnfwCfUK7g
1/pUJSC1lz/ckIP339DLZt4=
=fNEy
-----END PGP SIGNATURE-----

Post a reply to this message

In article <4138cdda$1@news.povray.org> , "Jérôme M. Berger" 
<jbe### [at] ifrancecom> wrote:

>  You do know that the ISO-C99 standard

For obvious reasons the ISO C++ 1998 standard cannot be a superset of the
ISO C 1999 standard.  Apart from this, while some ISO C 1999 features are
widely supported already, general support is still incomplete on many
platforms.

    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

On Fri, 03 Sep 2004 22:02:34 +0200, Jérôme M. Berger <jbe### [at] ifrancecom>  
wrote:

> 	You do know that the ISO-C99 standard defines uint32_t for an int
> type that's guaranteed to be 32 bits, don't you? It's in the stdint.h
> header


Unfortunately, that doesn't help much since C++ is based on C90. Some  
C++ compilers provide C99 compatibility as an extension, but then we're  
back at the portability issue.

In this case however, it's a non-problem, since POV-Ray won't work on  
platforms where 'int' is smaller than 32 bits anyway.



-- 
FE

Post a reply to this message

Slime <fak### [at] emailaddress> wrote:

> Well, duh. If an object is 1/10000 of the image's width, then of course it
> should be nearly invisible!

Yeah of course. This is why in reality there are never any stars visible in the 
night-sky ;-)

Lutz-Peter

Post a reply to this message

Christoph Hormann wrote:
> Vincent LE CHEVALIER wrote:
> 
>>
>> Is it possible to have HDR output with 3.6 ? I couldn't find anything 
>> about this in the doc...
> 
> 
> HDR output is supported in MegaPOV 1.1.
> 
> 
> Christoph
> 
Ok ! I'll have a look at it.

-- 
Vincent

Post a reply to this message