-
Notifications
You must be signed in to change notification settings - Fork 357
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
Dynamic range problem. #611
Comments
Dynamic range compression (drc) is a post-processing step. It won't help in this situation. You want exposure_compensation set to a positive value (units of 1/6 of a stop) to adjust the AE target point. |
We can try to do this, but I'm not sure if this will help us. I believe that it is necessary to disable the normalization of brightness and any noise reduction. |
If you're using manual exposure and gain then everything is on you to sort out. The camera sets the exposure and gain to the value you set it to. Pictures speak a thousand words. Show an example of what you're trying to do, preferably with the metadata for all the capture parameters. |
This is the main problem. I asked a colleague to pick up a night shot. |
A colleague sent an image file. |
If you are using raspistill. why are you raising the issue in the Picamera library which is a Python binding for the Pi camera? raspistill is part of userland - https://github.com/raspberrypi/userland/issues You've fixed exposure time, but done nothing for analogue gain or digital gain. AE/AGC will therefore be setting those based on the expected overall exposure of the frame. Add Exposure time can go up to 10seconds on IMX219, which gives you another 25% light. Pushing AWB digital gains to x8 for red and blue will give very odd colour casts when green is still at x1.0 (fixed). Actually without Capturing JPEGs also drops a load of more useful metadata in the EXIF. BMPs also include a further image conversion from YUV to RGB. If you're really wanting to mess with images in this way then you may be better off dropping back to the raw Bayer data. See https://github.com/6by9/raspiraw. Be prepared to take full responsibility for all settings at that point. |
I am sorry. Now Python is actively used under Linux along with the Bash and in my understanding the Python and Linux were not divided. My colleague also works with the Picamera library too. As for analog gain, as far as I know, we can only try to influence it indirectly, for example, through ISO. The final value is set by the camera processor. However, usage -ISO 800 improved the situation. The best thing, of course, would be to totally eliminate all the processing and auto-tuning that the processor does. We are used to work with special developed cameras that do exactly what we need. Namely, they give out a signal in direct proportion to the number of photons. And nothing more. We do the rest of the processing ourselves. But the development and manufacture of such cameras are very expensive. For example, only one special developed lens can cost $20,000 or more. But there is no such money. So there was an idea to take commercial off-the-shelf (COTS) device and use it. Thank you for the recommendations. We will work in the directions you indicate. |
Direct control of analogue and digital gains was added to raspistill in Oct 2017. I develop the firmware, and PiCamera has dropped behind a bit as I know waveform80 has other priorities at present, and it hasn't been added to PiCamera. Denoise operations can be disabled. Bayer denoise needs #571. |
The Raspi4 camera did not respond to the -ag 8.0 and -dg 2.0 options. It looks like the old version of raspistill is there right now. Unfortunately, the camera is now located about 1200 km from us. Physically, the camera will be available in two months. The camera itself was developed by my colleague Maslov I.A. The appearance of the camera can be seen in the attached figures. These cameras were designed to analyze the processes of absorption and scattering of light in the atmosphere. Unfortunately, even for daytime shots, the camera processor irreversibly spoils the image. Maslov I.A. will experiment with another camera for now. Do I understand correctly that disabling noise reduction is only possible when using the Python Library? |
So either update the Pi via apt, or rebuild userland for yourself to get the latest version.
Sorry, it's your job to ensure the camera module does what you want. The standard camera stack is written for taking standard webcam-type images.
No, but it's not exposed through raspistill/vid. See https://www.raspberrypi.org/forums/viewtopic.php?f=43&t=175711 |
As I wrote, now there is no SSH access to the camera. The camera Raspi4 read the command line from cloud storage. The command line is performed cyclically by the timer and serves only to change the shooting parameters of raspistill. What happens if we run the system update command in a loop is hard to say. Most likely, the camera will stop working at all. My colleague Maslov I.A. is planning gradual moving from raspistill to the Picamera library, since it has more features. Thank you very much for the consultations. |
Hi!
For the scenes of a large brightness dynamic range, the camera sets the maximum brightness of the image to 255, so the brightness of the dark areas is equal to zero. Is it possible to keep the brightness of dark areas in the image?
Bright image areas are out of interest.
The option "-drc high" does not improve the situation.
It is also possible that some kind of noise reduction algorithm is used in the camera.
In any case, irreversible image corruption occurs.
Is there any way to avoid this?
Camera Module v2 is used.
Thanks in advance!
The text was updated successfully, but these errors were encountered: