Sunday, December 21, 2014

Create Postage Stamp Window Border Theme in XFCE

I noticed that XFCE window themes allow transparent (color: None), so I thought it would be funny to create a postage stamp window border.  This was tested on Xubuntu 14.04

# The theme is based on greybird.  Copy the theme to a new one called 'bumpy'

cd /usr/share/themes/

sudo cp -r Greybird bumpy

cd bumpy/xfwm4/


# then update the border files

sudo vi left-active.xpm


/* XPM */
static char * left_active_xpm[] = {
"8 24 3 1",
"  c None",
". c #cecece",
"x c #939393",
"x.......",
" x......",
"  x.....",
"   x....",
"   x....",
"  x.....",
" x......",
"x.......",
"x.......",
" x......",
"  x.....",
"   x....",
"   x....",
"  x.....",
" x......",
"x.......",
"x.......",
" x......",
"  x.....",
"   x....",
"   x....",
"  x.....",
" x......",
"x.......",
};

sudo vi bottom-active.xpm

/* XPM */
static char * left_active_xpm[] = {
"23 8 3 1",
"  c None",
". c #cecece",
"x c #939393",
"........................",
"........................",
"........................",
"........................",
"...xx......xx......xx...",
"..x  x....x  x....x  x..",
".x    x..x    x..x    x.",
"x      xx      xx      x",
};


sudo vi right-active.xpm


/* XPM */
static char * left_active_xpm[] = {
"8 24 3 1",
"  c None",
". c #cecece",
"x c #939393",
".......x",
"......x ",
".....x  ",
"....x   ",
"....x   ",
".....x  ",
"......x ",
".......x",
".......x",
"......x ",
".....x  ",
"....x   ",
"....x   ",
".....x  ",
"......x ",
".......x",
".......x",
"......x ",
".....x  ",
"....x   ",
"....x   ",
".....x  ",
"......x ",
".......x",
};


sudo vi bottom-left-active.xpm 


/* XPM */
static char * left_active_xpm[] = {
"16 16 3 1",
"  c None",
". c #cecece",
"x c #939393",
"xxxxxxxx        ",
"xxxxxxxx        ",
"xxxxxxxx        ",
"xxxxxxxx        ",
"xxxxxxxx        ",
"xxxxxxxx        ",
"xxxxxxxx        ",
"xxxxxxxx        ",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
};


sudo vi bottom-right-active.xpm

/* XPM */
static char * left_active_xpm[] = {
"16 16 3 1",
"  c None",
". c #cecece",
"x c #939393",
"        xxxxxxxx",
"        xxxxxxxx",
"        xxxxxxxx",
"        xxxxxxxx",
"        xxxxxxxx",
"        xxxxxxxx",
"        xxxxxxxx",
"        xxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
"xxxxxxxxxxxxxxxx",
};


Now, your windows have postage stamp borders:


Sunday, December 14, 2014

Xubuntu 14.04 vs Linux Mint 17

I had been running Ubuntu on the desktop for a couple years.  For the last couple months I've been using both Xubuntu on my laptop and Linux Mint (Cinnamon) on my desktop.  Both are great desktop distros.  Here's a quick summary of the differences I've seen between the two.

Features: I like both distros Mint and Xubuntu and view them as roughly tied.   Generally Mint has more features, though a few areas feel like they could use more polish.   But this makes sense because Cinnamon a relatively new interface compared to XFCE, and it's not an official Canonical release.   Xubuntu is a bit leaner (fewer bells and whistles), but it is a very polished, light weight and a reliable workhorse OS.    Xubuntu is a bit like the Gnome2 desktop, possibly trimmed down.  In some ways, Xubuntu feels like Linux from the old days.   Some people might like this aspect of XFCE, though I can equally see how others might not.   XFCE reminds me both of Gnome2 (which was nearly flawless IMO) and my Redhat Linux desktop 15 years ago.   XCFE tends to take the more classic Unix approach of "one-tool-does-one-job."

Speed:  I like that XFCE let me easily turn off all desktop effects, including the compositor.  I don't see a way to disable compositor in Mint.  So, I would expect Xubuntu would run a little faster on older hardware.  Standards application load a hair faster in XFCE, such as Thunar file manager -- these applications are a bit more lean (fewer features).  Though I was surprised that some applications such as Chromium browser actually seem to load a hair faster in Mint (maybe because gnome dependencies?).   Overall though, on a normal computer, I don't notice much difference in speed between the two.

Menus/panels:  The only issue I've run into with Mint is in using Citrix Receiver, the bottom menu bar in  Cinnamon is always visible.  So, if I'm connected to a remote Windows machine, the Cinnamon menu sits on top of the Windows menu.  I haven't found a work around for this.  I see a similar issue in Xubuntu, but I can just select "Always On Top" from the menu bar, to bring the Citrix window to the front.  While XFCE *looks* slightly simpler, it seems to be remarkably configurable, and can do things that Unity can't even do (for example, move the menu bar to the bottom of the screen).

Repository integration: Xubuntu's software center is a bit sluggish to load, though I do like that I can install multiple applications from the listing.  Mint's software center runs faster, though I have to click the details page before I can install any application (a little more tedious).  I like the built-in ratings, but overall, both the GUI's are possibly harder to use than Synaptic Package Manager (or even the command line).

Upgrades: Xubuntu allows upgrades on a system (in-place), where Mint requires a full reinstall.   Granted, upgrades aren't always 100% reliable, so it might be best to avoid full upgrades.   But overall, the integration with Canonical's software repository feels a bit tighter in Xubuntu.  I  actually like that it prompts when updates are available.  In Mint, I have to remember to manually check for both software and kernel updates.

Default File Manager: Mint uses nemo and Xubuntu uses thunar.   Nemo includes a lot of conveniences out-of-the-box.

If I rename a file in the file browser, Mint functions exactly how  I'd expect -- the file is renamed in place.   Xubuntu (thunar) will pop up a new window that prompts for the filename.  I thought this pop up was odd, though it allows selecting multiple files to do a bulk rename.

I like that Mint makes it easy to create bootable USB flash drives (just right click on an ISO file).   I've never used these very much before, though having this baked into the file manager is nice.  It saves a lot of burnt cds and dvds when testing out software.

In Xubuntu, to get a similar convenience I had to install a usb package UNetbootin.  Open  thunar and go to Edit -> Configure Custom Actions, then add a custom command for *.iso files:

   unetbootin method=diskimage isofile=%f

The Thunar custom actions are saved in your home directory in the file .config/Thunar/uca.xml.   An alternate usb package is usb-creator-gtk (it looks nice, but only seems to work for Ubuntu iso's).

Similarly, Mint (with nemo) makes it a bit simpler to share folders over a network: right click on a folder and you have an option to share it.  In Xubuntu (thunar) you'll have to install packages samba and system-config-samba to manage shares.  Then tools are under the System settings.

There are not many default bookmarks (aka shortcuts)  in thunar's sidepane, though it is easy to add them if needed: right click a folder -> Send To -> Side Pane (create shortcut).

So, initially I wasn't a fan of thunar, though the missing functionality does make sense.  Thunar avoids duplication of system administration functionality,  yet it does make it fairly simple to add custom functionality if needed.  It is a valid question how much functionality/weight should be placed in the file manager if these operations are used infrequently.  

Firefox: I was surprised there's a prominent bug in Firefox in Mint, given that Firefox runs fine in all other versions of Ubuntu, and a browser is such a critical application.  For example: if I close multiple tabs, Firefox will prompt me if I want to save the multiple tabs -- every single time.  I check the box to stop prompting me, but it never remembers the preference.  The fix is simple (delete a config file), though it concerns me how this sort of bug is introduced and not patched, if the software is supposed to be 100% compatible with Ubuntu's repo's.

Codecs: In xubuntu, you have to install the package xubuntu-restricted-extras if you want all the proprietary codecs and fonts.  In Mint the codecs are already included.

Window borders: The standard Greybird theme in Xubuntu has 1px window borders which makes it nearly impossible to grab and resize the window.  There are a couple workarounds for this, though I wish there was an invisible region around the window border, like in Gnome.  Window borders in Mint are easier to use for resizing.  I had to tweak the theme in Xubuntu to use slightly thicker borders.

Default color schemes: Mint uses a green color scheme, which looks a little bit like whitish-green mint toothpaste to me.  I spent some time trying to change this to something else, but I didn't see an easy way to fundamentally change the color theme mint.  Most of the themes in the admin area seem to only change the menu launcher and window borders.  I did install another color theme, though to me all the choices looked over-saturated.  Eventually I just got used to the toothpaste colors in Mint.  Though this might be like the brown colors in Ubuntu.  Initially I thought Ubuntu was the ugliest distro I'd ever seen, though I got used to the brown and eventually missed the brown when they moved to pink and purple.  :)  Xubuntu's choice of colors -- blue, black, grey --  is probably a safer route.  Overall it looks clean.

Default Icons: I like the default Mint icons, especially for the home folder.  The Mint icons have a bit more variety, where the default Xubuntu icons are only one color.   Xubuntu does include the clean "Humanity" icons from core Ubuntu (though probably should include a blue-themed version).  I installed the package elementary-icon-theme from the repos.  

Default backgrounds: As superficial as a background is, it's fairly important in getting a first impression of a distro.   Initially, the first time I installed Mint, I thought it looked like a wash of confusing grey.  But when I changed the background to something darker, it became much easier to visually process.  So, I am not a fan of the light backgrounds when using a light grey window theme.  To me, it's too hard to see where the window stops and the background begins.  Also, I don't like backgrounds with too much complexity.  Personally, I just prefer darker blurry backgrounds to help make the windows stand out.  In this regard I wish Mint had some more options on the default backgrounds.  Xubuntu's default background is good enough, I never changed it.  In comparison, Fedora probably has the best collection of wallpaper's I've seen to date.

Mouse Scrolling: One unusual feature with XFCE is how it handles mouse scrolling.  When you scroll with the mouse, focus is transferred to the window the mouse pointer is above.  This is slightly different behavior than Mint/MS Windows, where focus only transfers to another window if you click it.  This might make it confusing if you move the mouse scroll button over the desktop background ... XFCE will cycle through the desktops.

Linux Mint XFCE: I only briefly looked at running XFCE on Mint.   Though, given that Xubuntu can be upgraded (usually LTS upgrades are painless) and Mint cannot be upgraded, I didn't see a whole lot of advantage of running XFCE on Mint vs plain old Xubuntu.  Any missing packages I install in Xubuntu would take less time than re-installing the whole Mint OS. 

Saturday, December 13, 2014

Increase Window Border Size in Xubuntu 14.04 Greybird Theme

I've been testing out Xubuntu 14.04 lately and I like the default Greybird theme.  Though I wondered how to change the width of the window borders.  By default the window borders are very thin -- only 1px wide -- making it nearly impossible to grab with a mouse and resize. 

TLDR:  If you just want a quick way to increase the border size, go to Settings -> Window Manager -> select Daloa.  Or try a couple different themes.  This will give you thicker window borders.

Granted, you can also resize XFCE windows a couple ways:

     http://xubuntu.org/news/window-resizing-in-xubuntu-and-xfce/




How Themes Work 

This section will explain how to customize the window borders in Greybird (or any theme).  

Here's a short article that explains how the theming works:

     http://wiki.xfce.org/howto/xfwm4_theme


The visual components are apparently defined as XPM3 files.   Overall, the file format is like ASCII art, where the characters can be mapped to colors.  For example, here is ASCII art representing the text "HI"
 x x  x
 xxx  x
 x x  x
The art is then wrapped in a syntax like C-code to describe the meta data. I'll define a 8x3 image having two colors.  It will using two characters ' ' (space) and 'x' for the ASCII art.  Below, the text in /* */ are comments that explain the file format: 


/* XPM */ 
static char * YOUR_VARIABLE[] = {
/* define a 8x3 image: width height colors chars_per_pixel */ 
"8 3 2 1",
/* define your colors: your_character c RGB_value, where 'c' is a literal */
"  c #ffffff",
"x c #000000",
/* now define the ascii art: rows of characters */
" x x  x ",
" xxx  x ",
" x x  x "
};

Then, if you look at the text, you can visually get a feel of the image ("HI"). The characters ' ' and 'x' are just defined to represent two different RGB values. Any two characters could have been used.


Here are two ways to increase the border size:


Method 1: Patch existing theme


To patch the Greybird Window borders, find the theme XFCE files under:
cd /usr/share/themes/Greybird/xfwm4/

Then, back up the files and try tweaking.  I'll increase the width to 4px and add a one pixel dark border.


sudo vi left-active.xpm
/* XPM */
static char * left_active_xpm[] = {
"4 24 2 1",
".      c #CECECE",
"x      c #7C7C7C",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x...",
"x..."};
sudo vi right-active.xpm
/* XPM */
static char * right_active_xpm[] = {
"4 24 2 1",
".      c #CECECE",
"x      c #7C7C7C",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x",
"...x"};
sudo vi bottom-active.xpm
/* XPM */
static char * bottom_active_xpm[] = {
"24 4 2 1",
".      c #CECECE",
"x      c #7C7C7C",
"........................",
"........................",
"........................",
"xxxxxxxxxxxxxxxxxxxxxxxx"};

sudo vi bottom-left-active.xpm
/* XPM */
static char * left_active_xpm[] = {
"8 8 3 1",
"  c None",
". c #cecece",
"x c #7c7c7c",
"x...    ",
"x...    ",
"x...    ",
"x...    ",
"x.......",
"x.......",
"x.......",
"xxxxxxxx" };
sudo vi bottom-right-active.xpm
/* XPM */
static char * left_active_xpm[] = {
"8 8 3 1",
"  c None",
". c #cecece",
"x c #7c7c7c",
"    ...x",
"    ...x",
"    ...x",
"    ...x",
".......x",
".......x",
".......x",
"xxxxxxxx" };

To trigger a refresh, you can run (in a terminal, as your user):


     xfwm4 --replace

The larger window borders look like:





So now the window borders are larger, easier to see and grab.


Also if you look at other themes, you'll notice the color definitions include a 'c' and an 's' value:


    "   c #CECECE s inactive_hilight_1",

The 's' is a gtk color name (as in the string or symbol).  If defined, it will override the hard-coded color.

Disclaimer: It would be better to copy the files and create a new theme.  Otherwise, you can deselect and reselect the window manager theme in your settings to reload it fully.


If the borders look dashed (due to video card rendering), you can increase the size of the image to improve tiling:
left and right:  4x24 px 
bottom: 24x4 px 
corners: 16x16 px

Method 2: Or, copy thick borders from existing theme Daloa

Daloa borders are 5px, and include a highlight.

# find your themes
cd /usr/share/themes

# Create copy of Greybird
sudo cp -r   Greybird   Greybird-thick

# copy borders from Daloa to new theme
sudo cp Daloa/xfwm4/bottom-active.xpm    Greybird-thick/xfwm4/
sudo cp Daloa/xfwm4/bottom-inactive.xpm     Greybird-thick/xfwm4/
sudo cp Daloa/xfwm4/left-active.xpm    Greybird-thick/xfwm4/
sudo cp Daloa/xfwm4/left-inactive.xpm    Greybird-thick/xfwm4/
sudo cp Daloa/xfwm4/right-active.xpm    Greybird-thick/xfwm4/
sudo cp Daloa/xfwm4/right-inactive.xpm    Greybird-thick/xfwm4/
sudo cp Daloa/xfwm4/bottom-left-active.xpm    Greybird-thick/xfwm4/
sudo cp Daloa/xfwm4/bottom-left-inactive.xpm    Greybird-thick/xfwm4/
sudo cp Daloa/xfwm4/bottom-right-active.xpm    Greybird-thick/xfwm4/
sudo cp Daloa/xfwm4/bottom-right-inactive.xpm     Greybird-thick/xfwm4/


# look at the colors defined in Daloa's bottom-active.xpm:
# "       c None",
# "+      c #E0E0FF",
# "@      c #A0A0FF",
# "$      c #B0B0B0",
# "#      c #C0C0C0",
# "########################",
# "########################",
# "########################",
# "++++++++++++++++++++++++",
# "@@@@@@@@@@@@@@@@@@@@@@@@"};


# Find/Replace the colors in the new theme with grey colors

sudo sed -i -e 's/C0C0C0/CECECE/'  Greybird-thick/xfwm4/*
sudo sed -i -e 's/A0A0FF/7C7C7C/'  Greybird-thick/xfwm4/*
sudo sed -i -e 's/E0E0FF/E0E0E0/'  Greybird-thick/xfwm4/*

# now update your theme
Settings -> Window Manager -> Pick the new theme "Greybird-thick"

# your new borders look like:






Wednesday, December 10, 2014

GNU/Linux and Google Trends


I noticed something interesting looking at Google Trends -- it looks like GNU/Linux searches are decreasing over time:



From:
http://www.google.com/trends/explore#q=%2Fm%2F03x5qm%2C%20%2Fm%2F0fpzzp%2C%20%2Fm%2F02wxtgw&cmpt=q


Though this strikes me as odd... since as of 2014, GNU/Linux probably holds the market shares (roughly):

  1. desktops:  1.5%
  2. servers:  40%
  3. smart phones/tablets: 84%
  4. super computers:  97%
From:

Also, most of these market shares are steady or gradually increasing.  Even on the desktop -- the smallest usage -- the market share has slowly inched up from 0.5% over the past ten years.  If there are 7 billion people on Earth, and about 5% own a computer,  that would mean roughly 5 million people are running Linux on the desktop now.  So why would Google trends be decreasing?  This seems to contradict all the other trends I've seen.

My guesses (based on my own search patterns)

1.  The numbers mean something different than what might be expected.  According to Google Trends, "A downward trending line means that a search term's popularity is decreasing. It doesn't mean that the absolute, or total, number of searches for that term is decreasing." So plausibly, now there are more people online searching for other things.  

2. The need for searching has changed.  About 15 years ago, when I started using Linux, I'd have to make a lot of continuous tweaks to get everything working the way I wanted.  Almost every installation resulted in multiple hardware or configuration problems.  Now, I install Linux and everything "just works" for me.  So I do very few searches now compared to ten years ago.  

3. General search terms are not needed.  I don't usually search for a broad term like 'linux' anymore.   I don't need to include it.  Usually I'll search for something much more specific.   

4. The web itself has become more specialized.  I'm more likely to check specific websites (like stackexchange, or distro forums) for answers rather than searching over the entire interwebs.   

So, if I restrict the trends to look at just YouTube stats, the trends look a bit more like what I'd expect from other stats -- a stable or slightly increasing line:


So, using  Google Trends (on the entire web) is not  a very accurate measure of overall interest or market share of technology.   Generally the numbers don't mean what might be assumed, since the search terms are competing against all popular searches.  For example: Linux vs Pop Celebrity of the Week or the latest Playstation Games :-).  

What might make the numbers more useful is to use one term as a base line, and normalize all other numbers relative to it.   For example, adding Windows as a baseline, and restricting the category to "Software > Operating Systems," it generally looks like searches are becoming less "techie" over time.  



Overall then, Ubuntu seems to have matched Linux in general search interest.  Also the gap between Windows and Linux is generally decreasing.  Which makes more sense.

In summary, Google Trends can offer some information, but it's fairly easy to misinterpret.  For example,  "android" has spiked in searches (see first graph), but "android" is really just a more specific type of "linux" search.  

Saturday, November 15, 2014

Minimalist Four Stroke Engine (codename: Batwing)

A while back I built a four-stroke engine kit for fun.  I had a few thoughts ...
  1. Hmm, so that's how they work  :-)
  2. That's how it works ?!
  3. All the circular to linear conversion of motion seems inefficient to me.
  4. The whole design seems to have too many parts for what it needs to do.
So, I started thinking about how I'd like to see a four stroke engine designed (in theory).  A couple design goals were:
  1. minimize the number of parts
  2. avoid the circular to linear conversion of motion
  3. increase the symmetry of design
So, to start, I wanted to use both ends of a piston for combustion.   This immediately cuts the components in half.  Also, this way the engine could reuse momentum for compression in the next cycle.

Though it can do better.  The whole mechanism can be reduced to use only one irregularly shaped piston.

Here's a rough sketch of the idea.  Suppose the piston and case are both circular (like a torus).  The piston nests inside the case.    Since both are circular, the piston can move freely inside the case, but create a seal.  The piston could oscillate in a clockwise and counter-clockwise motion inside the case.

While I sketched the piston as having flat sides, the original thought was more of a torus shape.  I thought a flat design would be simpler to machine though.   




Compression occurs between the end of the piston and the points A B C D.

Ignition occurs in the cycle:

    A  B  C  D

Vent and fuel lines are between B and C.  Also, between A and D.   If cams are used, they can be driven directly from the rotations off the piston axle (no need for timing belt).



Example of operation, focusing on A:
  1. Piston rotates clockwise compressing the fuel at A, igniting A
  2. Piston rotates counter-clockwise (away from A).  Fuel at B compresses and ignites
  3. Piston rotates clockwise (away from B) compressing A.   The spent fuel at A vents out.  C ignites.
  4. Piston rotates counter-clockwise (away from C and A, and towards B and D).  Fuel is injected into A as the space opens up.  It's ready for re-compression.  Goto 1
The other cases follow the same pattern (just re-label A B C D).

Since all the motion is circular, this simplifies the cams needed to control the vent valves.  Everything is moving around the same point of symmetry.

Power is tapped from the piston's axle as it rotates.

Possible issues I see would be:
  1. The compression force would want to bend the piston slightly, causing possible wear on the inside of the case.
  2. The piston would fire like a bullet into the next compression cycle  (diesel fuel might make more sense in this case).  The power would have to be tapped in a very controlled fashion, otherwise you don't want excess force slamming the piston into the other side.  
  3. It may be difficult to get a tight 3D seal.

Let me know if you see any issues with the concept/design.  I don't plan on building it... but the fun part for me is in the design part.

I call this thing a "Batwing Engine," named after that weirdly shaped piston.  :-)

Origami Puppet

Here's another attempt at creating a simple Origami toy puppet (well, it's not pure Origami if you cut the hair).   

The design is based off a shallow box like:



You'll need a long piece of paper (around 3x1).  Start by folding a long shallow box, but allow a bit extra paper on one end for hair.  




Then just fold the box over on itself.



Draw a face, and you have a kids toy :-)


Friday, November 14, 2014

Batman Safety Mask


Here's a batman mask that cracks me up:




especially with the warning label on the inside:




"Caution: For costume only.  Not to be used as a safety mask."


Oh noooooo ... now what I going to use to to weld with?!    ;-)

Monday, September 29, 2014

PXL 2000 Decoder

Special thanks to Mike Leslie for helping with the project.  Mike suggested using the first derivative of the signal, rather than direct AM signal (this smooths out the DC offset).  :-)

Previous I posted some old notes about the PXL 2000 video signal here.   Writing a decoder seemed like an interesting project, and it came together a bit faster than I expected.  Now it's fully functional, though could use a few tweaks.

This decoder can convert a PXL 2000 video signal from either a wav file or line-in to digital video.   In theory, you may be able to recover signal from tapes that no longer play in a PXL 2000 camcorder (with proper boost/compression).

Screenshot:



Features:

  • can decode from line-in or wav file
  • shows preview of decoded video
  • brightness/contrast control
  • speed control
  • sync controls
  • converts video signal to png frames
  • resamples audio to normal speed
  • creates a sample avconv script (with calculated fps) that will create a video file
  • saves time code of each frame
  • offers both GUI and command line modes

Requirements:

  • Java JDK 6+ to compile, and 
  • You'll need something like avconv or ffmpeg to merge the decoded png's and audio to a video format. 
  • If you use a wav file, the decoder is currently tuned for  stereo 16-bit audio sampled at 192khtz.


Source code and documentation is at:

    https://github.com/sevkeifert/pxl-2000-decoder


Saturday, August 30, 2014

Ubuntu 14.04 - Unity usability issues

I've used the Unity interface for a couple years now.  Initially I wasn't a fan, though I did see potential.  It's very forward-thinking, and geared for a time when people may have thousands of software applications installed.   And, half of these applications might not be installed locally at all, but instead reside in "the cloud" (which is where a lot of data and software is going).  In this light, the interface makes a lot of sense. 

At the same time, Unity is a fairly experimental (and somewhat unpopular) interface.  Just from a marketing perspective, I think the Canonical should present the xubuntu version of Ubuntu as the "flagship" workhorse desktop, with Unity presented as the touch-friendly and futuristic/experimental interface. 

Xubuntu uses  XFCE and the Whisker menu (which is simple and extremely usable).  Also, xubuntu runs well on older machines with a nice blend of features, design, and speed.  The Whisker menu looks like:


 (courtesy of http://gottcode.org)


In comparison, Unity's menu by default looks like:



My first impression is "that looks polished." In using it, however, there are several usability issues.
Instead of text or small icons, Unity uses large icons with large spaces.   That is fine, but not a lot of data can be shown in this small pop-up window.   Notice that very little data is shown, and most of the screen is now wasted space:



Instead, with such large icons, this screen really should be maximized by default:


However, the second problem here is that Unity uses transparency -- by default -- for the background of the menu.

 The problem here, there is so much information bleeding through the background that I can't even tell what I'm looking at, and I can barely read the words on the right.  To me, transparency doesn't look visually appealing.  It looks like the video card has a problem and it is now rendering random junk to the screen.

Transparency is not eye candy... it's really just clutter and bombards the user with millions of points of data that they have no need to see.  It honestly looks quite terrible and is not useful.  :)

The third problem is the interface violates the concept of "put commonly used items close together."  An interface should be like a super market... you put the toothbrushes and tooth paste next to each other.  But instead, suppose I open Dash, and I just want to see all my multimedia applications.  Look at the path my mouse (or touch) will travel:



These buttons couldn't be placed in a worse location, relative to each other.   One of the goals of Unity, I thought, was to reduce mouse/touch travel.  However here it objectively fails.  Granted you can use keyboard shortcuts on a desktop, though (a) it's still visually disorganized, (b) as things move towards tablets, there might not be an external keyboard, and (c) not everyone knows or wants to use keyboard shortcuts. 

Here are a couple ideas of how some of these UX issues can be fixed.

For starters, the menu screen should be on a solid background color by default, and it should be maximized by default.  

Of course, if someone wants transparency, they should have the option...

But, it's not even obvious how to change the background to a solid color.  You need to install Compiz's  settings manager -- CCSM.  The user will expect a right click or long touch either way.

Compare how much simpler this looks:


By comparison, the default transparent interface makes me feel like pulling the power cable out of the wall to reset the video card :)

As for the location of the buttons (bottom) and category filters (right), these should be grouped together.  

An interface should have a primary and secondary flow.  For English speakers, the page can read like a page of text, from top to bottom, left to right, mirroring the order of actions someone will perform while using the interface.

So, the bottom buttons would make more sense at top, with the filters on the left, for example: 



Here's a mockup with the filters expanded:


And for side-by-side comparison :)



For types of controls "what is performing actions vs what the target of action" should be separated visually.  For example, in the updated interface, search controls are on the left, search results are on the right.  Information that is not needed can be hidden by default. The whole interface has flow: top-left to bottom-right.

Though I think, once you do the work to filter down to a set of applications or files, there should be a way to save this set for later use.  Since usually I have groups of applications that I use.  For example: a group of applications for  creating audio, developing software, creating video, network tools, etc.    


Overall, there needs to be some easy way to save a set of applications as a new lens, and to assign an icon to it. 

For example:





 Otherwise, I actually have never used several of the lenses that are installed by default, and I've had Unity installed for a couple years. 

I tried using the global menus in Unity for a year or so, though ultimately they don't really save space.  What it does to is force a lot of extra mouse travel from the application and top of the screen.  I'm glad that Unity allows the menus in the window again.

Though I also see a lot of wasted space.  For example, the title bars are wasting the majority of the space:


Generally I don't look at a title bar to tell the difference between a terminal and Open Office, or a browser.  Amazing as it sounds, I think most people can actually tell the difference between apps by just looking at the application :)

So, it makes little sense to show the title by default, only to reveal the menu options on mouse over.  If I want to open the Edit menu, the current interface forces me to guess where "Edit" might be, I wait for the real location to reveal itself, then I have to visually re-process that the interface has changed, and I finally move to the correct location.  In other words, it's designed like a "Whack-a-mole" game.  

What might make much more sense would be to always show the title in the giant area of wasted space -- on the right.  The menu can then always be visible and functional:




That, or allow an option to show menu by default.  I'm not really interested in seeing the titles.

Also, one other feature that I think would improve user experience would be a launch button in the Software Center.  If someone installs a piece of software, there's a 90% chance they are  going to immediately run it after it installs.  Again, minimize the mouse travel by adding a launch button:



Also, if you place the menu options in the the title bar, the top bar is largely just wasted space.

Really it would make more sense if the lenses (the horizontal row of buttons in Dash) were always visible on the desktop.  That way, the left column of buttons would show a list of favorite applications, whereas the top row would show groups of applications/files by type.
 
Overall, the Unity interface is usable, though the user-experience is a bit rough-around-the-edges in spots.  It violates numerous interface design principles:

* an interface should have a primary and secondary flow that mirrors order of operations.  For example, top to bottom, left to right. 

* group commonly used items together closely

* don't waste space

* hide information that is not needed. 

* only show information needed when it is needed.  don't show information after it is needed.

* important items should be larger

* allow a user to save their work


 

Tuesday, August 12, 2014

PXL 2000 video signal format

For this post, we will look at the analog audio/video signals for the PXL 2000 camcorder, reverse engineer the signal formats, and build a working decoder.

Decoding the PXL 2000 Audio/Video Signal

I don't know if you remember these, but the PXL2000 is a handheld camcorder which was unique in that it recorded onto standard audio cassette tapes.



My camcorder no longer works, so I thought it  would be nice if there were some software that would convert or decode the analog signal on the tapes to a modern movie file. Granted, I could just fix my PXL 2000 camcorder, but I was curious how the PLX worked. :)

Since I couldn't find any existing software, I decided to put a little research into creating a decoder.

The first step is to reverse-engineering the raw analog signal format on my cassette tapes.

Fortunately I still have a working cassette player.   I just plugged this into my computer and digitized a section of tape.

I sampled the pxl 2000 video data at 192 khtz and viewed it in a wave editor. (44.1 khtz resolution will not work). The signal was VERY high pitched.

I boosted the video channel as much as possible without clipping. Here are screen shots of the wave in a wave editor:



(wide zoom)


(medium zoom)




(close zoom)





(192 khtz sample points in relation to signal size)
This is good.  There is a definite repeating pattern in the signal.  I was a little bit familiar with NTSC (which I expected) but the signal didn't look like anything I had seen before.  It looked like the PXL used it's own proprietary video signal.

Summary of signal format (rough guesses):

1. One of the stereo channels is used for video, one is used for audio (looks like standard analog wav format).

2. Looking at a wide zoom, it looks like amplitude is used to store video data. The entire video signal is roughly all at a constant frequency. (On my sample, there are occasionally small dc offsets in the AM...maybe because the tape is so old and it's bleeding over from audio channel?).

3. Long pulse every 92 packets probably demarcates an image frame (roughly every .5 sec at regular tape speed). This matches what is known about the frame rate. If the video is running about 15 fps, that means the data for a 92x110 video frame must be compressed within roughly 9/15 seconds (tape runs about 9x in camcorder)....just not enough room for any fancy encoding. Note, the long pulse is equal to two AM packets. Note sync signals are proportional to surrounding amplitude (seems exactly 5x larger than regular signal...may be usable video data I'd think it's unlikely).

4. Looking at the medium zoom, the small pulse signal probably demarcates a row of pixels (looks to be 110 oscillations in between). Amplitude modulation in between this sync signal probably describes brightness/darkness of 110 pixels. likely brightness(i) = posterize(amplitude(i), 8). These are probably all painted/recorded in real time, as opposed to buffering the pixels for a single time-slice. If you notice, occasionally there are sharp changes in the signal from a row the next row.

5. It is possible rows may be interlaced (note that some pixel rows appears to repeat a pattern ... halves sometime look like could align). The 110 length packet could be split in the middle...each half describing even and odd rows. Although: the images frames transition into the next very smoothly, which would suggest interlacing (perhaps an s-shaped path down and up?).


The video signal does not look exactly like NTSC to me...although it seems similar. The signal looks roughly like:









[long pulse signal about 230 oscillations long]
[
 [AM signal 110 oscillations] [5 small pulses] 
 [AM signal 110 oscillations] [5 small pulses] 
 ... 92 total AM packets... 
]
[long pulse signal about 230 oscillations long] 
[
 [AM signal 110 oscillations] [5 small pulses] 
 [AM signal 110 oscillations] [5 small pulses] 
 ... 92 total AM packets... 
]
...repeats....

So the video signal probably maps to:



[image frame sync signal]
[
 [row of 110 pixels] [sync signal] 
 [row of 110 pixels] [sync signal]
 ... 92 rows total ... 
]
[next image frame sync signal] 
...and so on...

Although I was puzzled why there are only 110 oscillations, as several people have reported 90x120 video. If that is true, I'd expect  90 packets of 120 oscillations -- unless I just can't count :).


Also, I  looked closer the sampled wave (@ 44.1 khtz) and noticed an odd pattern. The first two packets and last packet of the frame have a regular wave pattern (which is more easily seen at the lower sample rate).




(close up...regular patterns unlikely to hold interesting data.  Or black due to frame edge bleed.)

If this is significant, it only leaves 89 regular packets for data. This is odd, since it would be hard to explain where the 90th pixel's data is stored (if there are 90 pixels).

It looks like the long pulse might hold data, but that would be kinda silly (in my opinion). Maybe what is happening is that the tape speed changes slightly as the circuit prepares to ramp up for the large signal. Or, an edge of the image may always be dark, due to the camera.




In some cases the signal is so weak that no peaks are present (perhaps just my recording is bad, but I've tried to boost the signal as much as possible) So, only the large sync peaks can be reliably detected. It will be necessary to keep an average time between sync peaks for when the signal vanishes, or always divide the packet into 110 parts. See Figure:

 
It appears some signal that is bleeding over from the other tracks. Here is a clip of the audio and video data. You can see the video appears to have bled over into the audio track and vice-versa. Plus, as a tape sits for a long time, the tape will be sandwiched in a roll of tape that may transfer a magnetic signal to the next loop. makes me think the dc offset can be ignored... there doesn't seem to be any pattern to it.

Generally the audio/video signal makes sense, though oddly the data part seems slightly smaller than it should be.   However, the pixels on a TV aren't square, and it would be difficult to count them on a TV (as it is also hard to count them on a tape signal).
Building a decoder:
1. The hardest part on building a software converter would be parsing data from the slightly damaged analog signal.    The parser would need to be able to 
    a. detect relative peaks (primary AM signal)
    b. detect relative sync regions (regions louder than relative data)
    c. extract wave audio on second track
    d. handle damanged audio/video signal (missing signal, dc offset, clipping, etc)
Though, once the peaks/inflection points are extracted, I'd expect putting those back into an image would  be much more straight forward.
I did test out the Java Sound API a while back, but didn't think it was stable enough to build an analog parser with (at the time).
--
update 2014-09-08
I ran a quick test using java to decode the video, testing with a few random (sequential) frames.  This was a bit easier than I expected ...  I think I see my old drum set (the drums had clear heads with o-rings.   I think the dark spot is the 'tone control' or whatever it's called).  :)
This seems to confirm the basic video format, though needs quite a bit of tuning to clean up the sync:




 
I used the high and low points of the wave to construct the row, effectively doubling the width of number of pixels.  So, to fix the aspect ratio, it displays each row twice.   The signal was *not* interlaced (it was just coincidental that my first batch of wave samples were symmetrical).
--

Sample Decoded Video

Update 2014-09-10
 
I decoded a small sample of signal, and stitched the frames back together with avconv:
    
        avconv -r 15 -i frame_%05d.png movie.flv
It is definitely my old drum set:



The black/white values are inverted from what I initially thought.  A high signal is black, a low signal is white.   Which I suppose makes more sense from a storage perspective... you generally won't film the sun; filming a black or dark image is more common.
Aside from  tuning, now the decoder needs to parse audio (left track) and merge it with data (right track) at 15 frames/second.  
--
Update 2014-09-29
As suggested by T.Ishimuni, using the first derivative of the AM signal looks better than using the straight AM signal.  The straight AM signal looks a bit grainy to me, and I think is likely more distorted by  DC offset.   I included a patch so that the decoder can find either the first derivative (default) or direct AM signal.
--

PXL 2000 Decoder Software

I published all the code on github (GPL open source).  Code and documentation is here:


This decoder can convert a PXL 2000 video signal from either a wav file or line-in to digital video.   In theory, you may be able to recover signal from tapes that no longer play in a PXL 2000 camcorder (with proper boost/compression).

Screenshot:



Features:

  • can decode from line-in or wav file
  • shows preview of decoded video
  • brightness/contrast control
  • speed control
  • sync controls tab (allow fine-grain tuning for your specific signal)
  • converts video signal to png frames
  • resamples audio to normal speed
  • creates a sample avconv script (with calculated fps) that will create a video file
  • saves time code of each frame
  • offers both GUI and command line modes

Requirements:

  • Java JDK 6+ to compile, and 
  • You'll need something like avconv or ffmpeg to merge the decoded png's and audio to a video format. 
  • If you use a wav file, the decoder is currently tuned for  stereo 16-bit audio sampled at 192khtz.
The stable code is all the default "master" branch.  Any other branch should be functional but is more experimental.
--
Update 10/3/2018

Michael Turvey started a new project on github, using a FFT for sync detection... a great idea!  The project goal is to get the highest quality image from the analog signals.  Project details are here:

https://github.com/mwturvey/pxl2000_Magic