Orange dots are abstracts, light blue dots correspond to individuals who are first authors on an abstract, and dark blue dots correspond to the other author(s). You can view an interactive version here.

Orange dots are abstracts, light blue dots correspond to individuals who are first authors, and dark blue dots correspond to the other author(s). This visualisation should not to be interpreted as sets of in-groups/out-groups. It ignores past/future VSS co-authorships, casual collaborations, professional collaborations outside of VSS, and likely has inaccuracies due to the way authors’ names are analysed (see after the break for more). I am intrigued by the “scholarly social network” and this visualization is just one piece of a very incomplete puzzle.

There are often inconsistencies in author names (e.g., “Steven Cholewiak” vs. “Steven A. Cholewiak” vs. “Stëvèn Chólëwìäk”), so I use the difflib SequenceMatcher to calculate ratios of the names’ similarities and names that are very similar (a ratio of 0.9 or higher) are assumed to be the same. That is admittedly a very naïve method of dealing with naming inconsistencies (e.g., is “John Smith” the same person as “John Q. Smith” or “John H. Smith”?) but I’d love to see a favourable alternative.

You can view an interactive force-directed d3.js version here. The code for the graph and force-directed diagram generation is available on GitHub here. The notebooks can also be viewed using nbviewer.ipython.org:

• visvssrelationships_scrape.ipynb
• visvssrelationships.ipynb

While browsing the web, I found a table listing the calories in a number of beers and thought it would be interesting to visualize using Python and plot.ly. It is a simple visualization, but one I find neat. Without further adieu:

Each blue point on the plot is a beer from the beer100.com domestic and international tables — feel free to explore the plot with your mouse. As you can see, unsurprisingly, as a beer’s alcohol content increases, so do the number of calories. Fitting a linear regression to the data, we see that a linear trend fits quite well: $latex f(x) = (28.2)*x + (8.25)$, where $latex x$ is the beer’s ABV (in percent). This means that if a beer has an alcoholic content of 5%, we can expect it to have approximately 150 calories (149.25 as predicted by the fit). However, there is quite a bit of variability between different beers of the same ABV. For example, Bud Ice Light and Kronenbourg Imported Dark Beer (whose label is a bit ambiguous, but I am assuming may be Kronenbourg 1664 Brune) are both 5% ABV, but have 115 and 163 calories per 12 oz, respectively.

In addition to the data points, I’ve also included a line illustrating the calories for pure ethanol as a function of ABV (assuming it is mixed with water to dilute it). This could be considered the “alcohol purity line” for empty calories (i.e., this would be the closest to a neutral spirit). If you compare light to non-light beers (done using a simple if “Light” is in name), you can see that the light beers are shifted closer to the pure ethanol line:

This simple string comparison misses a number of light beers (like Miller Genuine Draft 64 and Budweiser Select 55 which are also closest to the “alcohol purity line”), but captures the general trend. However, note that the more (in my humble opinion) flavorful and interesting beers lie above the original linear fit line.

Finally, I wanted to quickly compare the beer100.com data to brewer-supplied information. Unfortunately, most brewers avoid disclosing their nutritional facts; however, Anheuser-Busch and MillerCoors are relatively transparent, providing some facts about their beers and malt beverages. After normalizing the data to a 12oz serving size, we can see that, like the beer100.com data, there is quite a bit of variability.

The dark orange circle in the center is myself, light blue circles are papers/presentations, light orange circles are co-authors, and dark-blue circles are co-authors of my co-authors (i.e., have not necessarily directly worked with me on a project).

Unfortunately, as of today, not all of my co-authors have Google Scholar pages, so there are a number of co-authors whose connections and branches are under-represented.  In addition, Google Scholar does not necessarily accumulate all of a given author’s papers/presentations and often makes mistakes misattributing papers to profiles.  So, the veracity of the information represented here should be taken with a grain of salt unless I find a better service for generating these networks.

For some more information on how this was created, click-through to the post.

As with the VSS DNA graph I made before the Visual Sciences Society Annual Meeting this past May, I used Python, NetworkX, and D3.js.  In addition, I took advantage of another Python module, GoogleScholar, to screen-scrape information from the Google Scholar profiles.

Starting with my Google Scholar citation profile, I loop through the individual entries and extract the titles and co-authors of each entry.  The names and titles are connected as nodes using NetworkX.  I then had a list of co-authors:

• Ari Weinstein
• Benjamin Kunsberg
• Bernard D Adelstein
• Bina Pastakia
• Chia-Chien Wu
• Chris L Baker
• David S Ebert
• E Daniel Hirleman
• Flip Phillips
• Gaurav Kharkwal
• Hong Z Tan
• Jacob Feldman
• Joshua B Tenenbaum
• Julia E. Mazzarella
• Kevin Sanik
• Kristina Denisova
• Kwangtaek Kim
• Manish Singh
• Matthew B Kocsis
• Melissa M Kibbe
• Paul Ringstad
• Peter C Pantelis
• Roger W. Cholewiak
• Roland W Fleming
• Ryan M Traylor
• Steven W Zucker
• Sung-Ho Kim
• Tim Gerstner

To create the connections, I search for the co-authors names on Google Scholar (the profiles that were used are linked above) and do the same thing, extracting the titles and (co-?)co-authors names.  This allowed me to produce a network diagram illustrating individuals who have been my co-authors, along with co-authors of those co-authors.  Many of my co-authors did not have profiles when I generated this first version and there were a few with technical problems (e.g., one profile was populated with a large number of papers from another individual with the same name as my co-author, but a different person, and pruning these problematic entries would have been labor intensive).  Still, it is a neat illustration worth sharing.

I am not currently including the code on this page because it is quite messy and “non-pythonic”, but I’m happy to share it if there is interest.  In addition, since this image was produced with D3.js, there is an interactive version of the graph available. I chose not to include it because it can be quite computationally taxing with the large number of nodes and connections and therefore not the best for directly including on the blog.

UPDATE June 20, 2014: I removed the co-author labels from the lead image because I don’t want to give the false impression that specific co-authors are better connected than others.  Since this visualization is dependent on a 3rd party scraping service, it is problematic to draw any conclusions about “connectedness” from this representation.

As you can see, there are large numbers of abstracts that have few shared authors.  Those abstracts that share authors often join together to create “chains” of students, advisors, and colleagues.

This is a first version, hastily pulled together, so there are a few problems.  The nodes are assigned to authors by name, which can be a problem for authors sharing the same name (which creates more connections than appropriate for a given node) or who  have inconsistent reporting of their name (for example, omitting the middle initial or alternate spelling, which can create another erroneous node). I am thinking of addressing the duplicate node issue by using a string similarity metric (e.g., Levenshtein distance) to find strings that contain similar names to combine the connections, but this could be an issue if the names are truly different people. Alternatively, I could incorporate the authors’ affiliations, but this carries similar issues (e.g., I report my affiliation as “University of Giessen” while colleagues report it as “Justus-Liebig-Universität Gießen”).

Although there are lingering issues, it is still an interesting illustration of the connections between the different abstracts being presented at VSS 2014.

Here’s the code on GitHub: visvssrelationships

There is a bit of distortion (see Tissot’s indicatrix), especially at the top and bottom of the image, but this is due to the problem of projecting a sphere onto a plane. On the Nexus 5 (and other GPE phones), the Gallery application includes a feature that allows you to either view the resulting Photo Spheres as spherical panoramas or to create “Little Planets”/”Tiny Planets”, which are actually Stereographic Projections of the spherical panorama. I found the effect really neat, so I wanted to see if I could recreate the projection in MATLAB.

As a teaser, here’s the output for my code:

Click through to get more information on the MATLAB implementation.

I found some Flash code that performs a similar function to what I wanted to achieve, so I have to send a big thanks to nicoptere for providing his code for PIXEL BENDER #4 projections. Thanks to the examples provided in his code, I was able to translate the projection conversion into MATLAB.

The actual calculation of stereographic projections is well documented on Wolfram Mathworld’s Stereographic Projection page, but basically we only need the last bit dealing with the inverse formulas for latitude $latex \phi$ and longitude $latex \lambda$. We can then use that to map the points onto our Equirectangular projection produced by the Photo Sphere function to points on a Stereographic projection. I am including the MATLAB code for the function at the end of the post, but here are a couple of examples of the conversion.

First, just to illustrate how the stereographic projection affects the Tissot’s indicatrix, here is an example based upon a equirectangular world projection from Wikipedia user Eric Gaba (CC BY-SA 3.0):

As you can tell, the output is a function of the latitude and longitude, with the “lowest” latitude in the middle of the image and the “highest” outside the bounds of the projection. This means that Antarctica is in the center while Arctic Circle is not visible.

If we apply the equirectangular to stereographic projection function to my image at the top of the post, but sample from the highest latitude for the center of the output image (by inverting the viewing distance in the code below), we can create another visually compelling projection:

For anyone who is interested, here is the function used to generate the equirectangular to stereographic projections (“Little Planets”) in MATLAB. Note that this function requires the inpaint_nans function:

Note that the Handbrake CLI options are defined in runstr. As-is, the script will convert videos with AVI, DIVX, FLV, M4V, MKV, MOV, MPG, MPEG, and WMV extensions to H.264 MP4s with the following options:

• “Normal” preset
• Two-pass encoding
• Turbo first pass, which “significantly boost[s] the speed of the first pass – with minimal effect on quality”

There are a number of GoPro editions, but the newest one are the Hero3+ Silver and Black. The Silver Edition is very similar to the GoPro Hero3+ Black Edition (Amazon), but omits a few features, including some very high-resolution video recording modes and a feature that GoPro calls “Superview”. This post talks about a way that I attempted to emulate their Superview mode in MATLAB and put together an adaptive aspect ratio function that allows one to change the image’s aspect ratio while maintaining “safe regions” with minimal distortion.

This function allowed me to resize 4:3 images and video, like this one:

To a wider aspect ratio, for example 16:9:

Click through for info on how I implemented the code.

Let’s say we have an original, 4:3 image or frame from a camera (GoPro in this instance):

If we want to convert it to 4:3 format, we have a couple of options. The simplest is cropping out the top and bottom of the image:

The issue with cropping is that it cuts down on the vertical field of view. We could alternatively scale the image in the horizontal direction (or compress in the vertical, the effect is the same):

As you can see, scaling causes distortion in the image that can be distracting, especially when there are known points of reference (like people) in the frame.

An alternative to cropping or linear scaling, is the GoPro Hero3+ Black’s Superview mode, which is intended to non-linearly scale the image to retain as much vertical image information while attempting to minimize the perceived scaling distortion, especially in the center of the image frame.

Here is a description of the GoPro Superview feature, according to GoPro:

SuperView is a new feature introduced with HERO3+ Black Edition which allows you to capture an immersive wide angle perspective. What this mode does is it takes a 4:3 aspect ratio and dynamically stretches it to a 16:9 aspect ratio. This can be a great choice because it uses the height of the camera’s sensor that you get with 4:3 meaning that you will see more of the sky and ground assuming you are pointed at the horizon. … The way it works is that the camera automatically stretches out the sides of the video to fit into the 16:9 frame. The center of the frame is unchanged, only the edges are adjusted.

This sounds as though there is 1:1 mapping of pixels in the center of the frame with gradual distortion/interpolation towards the right and left edges. This would maintain the total field of view and information content in the image, while attempting to conform to a widescreen aspect ratio.

Abe Kislevitz has a nice discussion of 4:3 to 16:9 footage conversion with the GoPro and specifically discusses a plugin called Elastic Aspect. I chose to do a similar transformation in MATLAB to see if I could reproduce the Superview effect in “post production” (after an image or video has been captured).

To do this, I created a 1-Dimensional mapping of the input pixels to the output pixels along the y-axis and remapped the locations of pixels that were not linearly mapped to “Safe Zones’ using cubic spline interpolation.

Let’s say I want to stretch GoPro image of my wife and I from 4:3 to 16:9 widescreen aspect ratio. Here’s the original 4:3 image:

Using linear interpolation, this would be the expected mapping (and resulting image). Note the distortion in our faces:


Created using the following code (from the below function):

[code lang=matlab]
outImage = bSplineResizeWidth([1080,1920], inImage, [50 50]);
[/code]

With cubic spline mapping with a very small “Safe Zone” that is linearly mapped (5% of the image width), we would have this mapping and resulting image:


Created using the following code (from the below function):

[code lang=matlab]
outImage = bSplineResizeWidth([1080,1920], inImage, [47.5 52.5]);
[/code]

Notice the difference in perceived quality already? Now, let’s protect the center 25% of the image:


Created using the following code (from the below function):

[code lang=matlab]
outImage = bSplineResizeWidth([1080,1920], inImage, [37.5,62.5]);
[/code]

Looking good! Let’s say our subject is off to the side of the image, we can explicitly choose those regions to “protect” by ensuring a 1:1 mapping to avoid any distortion for our subject. For example, here’s a picture of my cousin’s husband, located slightly off-center:

I can explicitly select a “Safe Zone” around his body to avoid distorting him further. Here’s the remapping and resulting image:


Created using the following code (from the below function):

[code lang=matlab]
outImage = bSplineResizeWidth([1080,1920], inImage, [], 1);
[/code]

So, although there is still inevitable distortion around the outside of the image, it seems as this may be an effective way to emulate GoPro’s Superview mode and perform an adaptive aspect ratio adjustment.

For the sake of discussion, there is another method called seam carving (commonly known as content-aware scaling with Adobe Photoshop), but this can introduce some artifacts, depending on the scene. It is also quite slow. Here is an example implementation in MATLAB by Danny Luong: Seam Carving for content aware image resizing: GUI implementation demo. In general, it appears as though seam carving is better suited for images rather that videos (note that the original authors of the algorithm developed a similar method for processing video):

Here is the code for both procedures: