> 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