hodapp/blag
1
0
Fork 0
Code Issues Pull Requests Packages Projects Releases Wiki Activity

Finished pi-pan-tilt post part 3

Browse Source
This commit is contained in:
Chris Hodapp 2016-10-16 18:12:18 -04:00
parent a179e11165
commit e3476bc5bb
2 changed files with 45 additions and 13 deletions
Show Stats Download Patch File Download Diff File Expand all files Collapse all files

4
posts/2016-10-04-pi-pan-tilt-2.md
View File

@ -139,8 +139,8 @@ However, you can look up close and see how well the details came
through - which I find quite impressive for cheap optics and a cheap
sensor.
Further posts will follow on some other details, and hopefully other
images!
[Part 3](./2016-10-12-pi-pan-tilt-3.html) delves into the image
processing workflow.
[ArduCam]: http://www.arducam.com/camera-modules/raspberrypi-camera/
[forum-raw-images]: https://www.raspberrypi.org/forums/viewtopic.php?p=357138

54
posts/2016-10-12-pi-pan-tilt-3.md
View File

@ -8,7 +8,8 @@ tags: photography, electronics, raspberrypi
This is the third part in this series, continuing on from
[part 1][part1] and [part 2][]. The last post was about integrating
the hardware with Hugin and PanoTools. This one is similarly
technical and without as many pretty pictures, so be forewarned.
technical, and without any pretty pictures (really, it has no concern
at all for aesthetics), so be forewarned.
Thus far (aside from my first stitched image) I've been using a raw
workflow where possible. That is, all images arrive from the camera
@ -156,26 +157,54 @@ These were done with 16-bit TIFFs rather than 8-bit ones:
In theory, the 16-bit ones should be retaining two extra bits of data
from the 10-bit sensor data, and thus two extra stops of dynamic
range, that the 8-bit image cannot keep. I can't see the slightest
difference myself. Perhaps those two bits are just well below the
noise floor; perhaps if I used a brighter scene, it would be more
apparent.
difference myself. Perhaps those two bits are below the noise floor;
perhaps if I used a brighter scene, it would be more apparent.
Regardless, starting from raw sensor data rather than the JPEG image
gets some additional dynamic range. That's hardly surprising - JPEG
isn't really known for its faithful reproduction of darker parts of an
image. Regardless, bracketing exposures and merging them later (as
Hugin will do) is probably a better idea than pretending the sensor is
going to give 10 bits of resolution.
image.
Here's another comparison, this time a 1:1 crop from the center of an
image (shot with [this lens][12-40mm], whose Amazon price mysteriously
is now $146 instead of the $23 I actually paid). Click for a lossless
PNG view, as JPEG might eat some of the finer details.
image (shot at 40mm with [this lens][12-40mm], whose Amazon price
mysteriously is now $146 instead of the $23 I actually paid). Click
the preview for a lossless PNG view, as JPEG might eat some of the
finer details, or [here][leaves-full] for the full JPEG file
(including raw, if you want to look around).
[![JPEG & raw comparison](../assets_external/2016-10-12-pi-pan-tilt-3/leaves_test_preview.jpg){width=100%}](../assets_external/2016-10-12-pi-pan-tilt-3/leaves_test.png)
The JPEG image seems to have some aggressive denoising that cuts into
sharper detail somewhat, as denoising algorithms tends to do. Of
course, another option exists too, which is to shoot many images from
the same point, and then average them. That's only applicable in a
static scene with some sort of rig to hold things in place, which is
convenient, since that's what I'm making...
[![Shot setup](../assets_external/2016-10-12-pi-pan-tilt-3/IMG_20161016_141826_small.jpg){width=100%}](../assets_external/2016-10-12-pi-pan-tilt-3/IMG_20161016_141826_small.jpg)
I used that (messy) test setup to produce the below comparison between
a JPEG image, a single raw image, 4 raw images averaged, and 16 raw
images averaged. These are again 1:1 crops from the center to show
noise and detail.
[![JPEG, raw, and averaging](../assets_external/2016-10-12-pi-pan-tilt-3/penguin_compare.jpg){width=100%}](../assets_external/2016-10-12-pi-pan-tilt-3/penguin_compare.png)
Click for the lossless version, and take a look around finer details.
4X averaging has clearly reduced the noise from the un-averaged raw
image, and possibly has done better than the JPEG image in that regard
while having clearer details. The 16X definitely has.
Averaging might get us the full 10 bits of dynamic range by cleaning
up the noise. However, if we're able to shoot enough images at
exactly the same exposure to average them, then we could also shoot
them at different exposures (i.e. [bracketing][]), merge them into an
HDR image (or [fuse them][exposure fusion]), and get well outside of
that limited dynamic range while still having much of that same
averaging effect.
I'll cover the remaining two steps I noted - Hugin & PanoTools
stitching, and postprocessing - in the next post.
stitching and HDR merging, and postprocessing - in the next post.
[part1]: ./2016-09-25-pi-pan-tilt-1.html
[part2]: ./2016-10-04-pi-pan-tilt-2.html
@ -197,3 +226,6 @@ stitching, and postprocessing - in the next post.
[picamera-raw]: https://picamera.readthedocs.io/en/release-1.10/recipes2.html#bayer-data
[picamera]: https://www.raspberrypi.org/documentation/usage/camera/python/README.md
[12-40mm]: https://www.amazon.com/StarDot-Vari-Focal-Camera-Lens-Black/dp/B00IPR1YSC
[leaves-full]: ../assets_external/2016-10-12-pi-pan-tilt-3/leaves_test_full.jpg
[exposure fusion]: https://en.wikipedia.org/wiki/Exposure_Fusion
[bracketing]: https://en.wikipedia.org/wiki/Bracketing