Image normalization idea for light9 previews
Original problem: I want to combine images of individual theater lights to simulate what it would look like if they were turned on in some combination of brightnesses. That's fine, but when my input image has a washed out area at the hotspot of the light, 50% of that image will not be correct. There will be a gray splotch in the shape of the hotspot. Here's a demo using a desklamp in my room:

Solution: Use High Dynamic Range images that contain relative brightnesses even inside a washed-out area. With a low-end camera like mine, I can take multiple exposures of the scene and then reassemble them automatically into an HDR image. Tools that might be able to do this include cinepaint, HDR Shop, and qtpfsgui. Then when I want to see a particular mix of lights, I add my per-light HDR images with the appropriate scale factors and clip the result to white. The result should be like I took a real photo of that light combination.
New problem: Unless my input images (HDR or not) are all calibrated to the same brightness scale, my resulting image will be incorrect. E.g. if light1 is dim and light2 is bright, my simple camera will probably auto-expose light1 to be brighter than it really is and vice versa on light2. My resulting images will be incorrectly low-contrast-- each light will have been adjusted towards the middle. If I use my digital camera to take the photos, I might be able to get some EXIF correction data. But if I use my laptop webcam, I don't think I can ever learn the auto-adjustment level. It would be nice to know the scale factor of each of the input images so we can normalize them before adding them.
New solution: After taking the per-light images, take another picture that has all the lights on (or a few pics of various known combos). Then solve for the scale factors on each light's image that would lead to the measured combo image. Each pixel in the allLights image is a combination like this:
scale1*light1(x,y) + scale2*light2(x,y) + ... = scaleAll*allLights(x,y)
There are a lot more pixels in each image than there are unknown scale factors, so this should be solvable. Once we figure out the scale factors, we can start making accurate sums of the input images.
Atom feed of this blog
<class 'rdflib.syntax.parsers.n3p.n3proc.ParseError'> at /public/comments
Illegal literal character: u'\r'
Traceback (innermost first)
/usr/local/lib/python2.6/dist-packages/rdflib-2.4.1-py2.6-linux-x86_64.egg/rdflib/syntax/parsers/n3p/n3proc.pyinunquote/usr/local/lib/python2.6/dist-packages/rdflib-2.4.1-py2.6-linux-x86_64.egg/rdflib/syntax/parsers/n3p/n3proc.pyinliteral/usr/local/lib/python2.6/dist-packages/rdflib-2.4.1-py2.6-linux-x86_64.egg/rdflib/syntax/parsers/n3p/n3proc.pyinliteralFinish/usr/local/lib/python2.6/dist-packages/rdflib-2.4.1-py2.6-linux-x86_64.egg/rdflib/syntax/parsers/n3p/n3proc.pyinonFinish/usr/local/lib/python2.6/dist-packages/rdflib-2.4.1-py2.6-linux-x86_64.egg/rdflib/syntax/parsers/n3p/n3p.pyinparse/usr/local/lib/python2.6/dist-packages/rdflib-2.4.1-py2.6-linux-x86_64.egg/rdflib/syntax/parsers/n3p/n3proc.pyinparse/usr/local/lib/python2.6/dist-packages/rdflib-2.4.1-py2.6-linux-x86_64.egg/rdflib/syntax/parsers/N3Parser.pyinparse/usr/local/lib/python2.6/dist-packages/rdflib-2.4.1-py2.6-linux-x86_64.egg/rdflib/Graph.pyinparse/usr/local/lib/python2.6/dist-packages/rdflib-2.4.1-py2.6-linux-x86_64.egg/rdflib/Graph.pyinparse/my/site/blog/baby/commentServe.pyingetGraph/my/site/blog/baby/commentServe.pyinGET/usr/local/lib/python2.6/dist-packages/web.py-0.34-py2.6.egg/web/application.pyinhandle_class/usr/local/lib/python2.6/dist-packages/web.py-0.34-py2.6.egg/web/application.pyin_delegate/usr/local/lib/python2.6/dist-packages/web.py-0.34-py2.6.egg/web/application.pyinhandle/usr/local/lib/python2.6/dist-packages/web.py-0.34-py2.6.egg/web/application.pyinprocessRequest information
INPUT
COOKIES
No data.
META
ENVIRONMENT
You're seeing this error because you have
web.config.debugset toTrue. Set that toFalseif you don't to see this.