Skip to main content

Hmm...

I was reading an essay by a photographer who shoots 4x5 format for landscapes. Its very entertaining to read about how he focuses on a ground glass screen and then uses a loupe to check focus. But here's a sentence that I found entertaining because its technically wrong, but I think I know what he means:

"Fourth, the inverted image on the ground glass creates a more direct visual impression because the brain does not have to flip the image upside down. This last remark is based on the fact that our eyes act as lenses and thus project an upside-down image of the world to the brain, which then has to flip it right side up. Because the ground glass image is inverted it is projected to the brain right side up thereby nullifying the need for the brain to rectify the image."

Its hard to explain why this is wrong but basically the brain is used to how it gets the images and it is harder for the brain to process an upside down image. Consider the empirical results that we find it harder to recognize upside down faces, and read upside down writing.

But I think what the author (Alain Briot) experiences is his brain reacting to the novelty of the upside down image. Because the image is upside down, and is harder to recognize, his brain starts to analyze the picture as individual components (note his use of the loupe to focus). At this stage of the artistic process he is trying to extract detail from little pieces of the image (hence his need for large format). The upside down image forces him to do this.
Labels:

Comments

Post a Comment

Popular posts from this blog

A note on Python's __exit__() and errors

Python's context managers are a very neat way of handling code that needs a teardown once you are done. Python objects have do have a destructor method ( __del__ ) called right before the last instance of the object is about to be destroyed. You can do a teardown there. However there is a lot of fine print to the __del__ method. A cleaner way of doing tear-downs is through Python's context manager , manifested as the with keyword. class CrushMe: def __init__(self): self.f = open('test.txt', 'w') def foo(self, a, b): self.f.write(str(a - b)) def __enter__(self): return self def __exit__(self, exc_type, exc_val, exc_tb): self.f.close() return True with CrushMe() as c: c.foo(2, 3) One thing that is important, and that got me just now, is error handling. I made the mistake of ignoring all those 'junk' arguments ( exc_type, exc_val, exc_tb ). I just skimmed the docs and what popped out is that you need to return True or...
Post a Comment
Read more

Store numpy arrays in sqlite

Use numpy.getbuffer (or sqlite3.Binary ) in combination with numpy.frombuffer to lug numpy data in and out of the sqlite3 database: import sqlite3, numpy r1d = numpy.random.randn(10) con = sqlite3.connect(':memory:') con.execute("CREATE TABLE eye(id INTEGER PRIMARY KEY, desc TEXT, data BLOB)") con.execute("INSERT INTO eye(desc,data) VALUES(?,?)", ("1d", sqlite3.Binary(r1d))) con.execute("INSERT INTO eye(desc,data) VALUES(?,?)", ("1d", numpy.getbuffer(r1d))) res = con.execute("SELECT * FROM eye").fetchall() con.close() #res -> #[(1, u'1d', <read-write buffer ptr 0x10371b220, size 80 at 0x10371b1e0>), # (2, u'1d', <read-write buffer ptr 0x10371b190, size 80 at 0x10371b150>)] print r1d - numpy.frombuffer(res[0][2]) #->[ 0. 0. 0. 0. 0. 0. 0. 0. 0. 0.] print r1d - numpy.frombuffer(res[1][2]) #->[ 0. 0. 0. 0. 0. 0. 0. 0. 0. 0.] Note that for work where data ty...
Post a Comment
Read more