Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Units for scene files #407

Closed
lobneroO opened this issue Jan 3, 2024 · 6 comments
Closed

Units for scene files #407

lobneroO opened this issue Jan 3, 2024 · 6 comments

Comments

@lobneroO
Copy link

lobneroO commented Jan 3, 2024

I am trying to set up scene for testing PBRT for my use case and am looking at the Input File Format Documentation . A lot of the set ups do not have any units associated with them. This makes it hard to set up correctly and compare to other rasterizers.
E.g. The shuter open and close time are 0 and 1. Are these micro seconds? Nano seconds?
Same for the light power intensity. This does not even have a default for me to guess a sensible value.

Can units be added to the scene documentation?

@rainbow-app
Copy link

rainbow-app commented Jan 10, 2024

I'm no substitute for mmp, but here are my 5 cents.

Often it doesn't make huge sense to specify/require "units". Suppose you have algorithm that computes distance travelled by a point with const velosity. The "algorithm" will just spit out the product v*t, and the units will be determined by whatever units have your input data.

I think you can generally assume it's all in SI.

As to light intensity, if it has same RGB (=gray), and if light is point, you can specify it in candellas (cd=lm/sr; it will be luminous intensity then), thus factoring the eye-sensitivity curve into the intensity. The output will be luminance (cd/m^2; for exposure=1s). 100lux is good illumination, at distance 10m you'll need 10000cd. The proper way is to specify intensity in physics-based units (like Watt instead of lumen), over wavelengths, but I never did it. "Point and gray" was my only use case in v3.

Disclaimer: I don't know v4.

@mmp
Copy link
Owner

mmp commented Jan 13, 2024

@rainbow-app is right: it's all SI. Meters for distance, W/(m^2 sr) for radiance, power and radiant intensity per SI, etc. Time is seconds. I agree that it would be good to be clear about that in the documentation and will make a note to do so.

@lobneroO
Copy link
Author

@mmp Time is seconds. That probably doesn't hold true for the shutter open/close time, right?

@mmp
Copy link
Owner

mmp commented Jan 15, 2024

Nope, it does. (Why wouldn't it?)

@lobneroO
Copy link
Author

I increased the shutter close to 200 for a scene of mine to get quickly visible results for debugging purposes. This worked well, but in a real camera I would expect a 200 second shutter time to lead to practically just a white image.

Since I am not a photographer, I just did a sanity check on wikipedia, the shutter speeds listed are not really exceeding 1 second and a lot of them are well below that.

@mmp
Copy link
Owner

mmp commented Jan 16, 2024

You seem to be assuming that pixel values will be between [0,1] for display. Strictly speaking (and with pbrt's RealisticCamera), a camera sensor is measuring energy in Joules over each pixel area; see https://www.pbr-book.org/4ed/Cameras_and_Film/Film_and_Imaging#TheCameraMeasurementEquation and equation 5.5. So in general you will need to remap those measurements to your display's range (e.g. by scaling them).

@mmp mmp closed this as completed Jan 25, 2024
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Labels
None yet
Projects
None yet
Development

No branches or pull requests

3 participants