I have an old post about how to change the document colors in Okular, and it gave no toggle options. Here I post an updated version for you who might be want to invert the colors of your PDF files in Okular (I myself always need this kind of toggling functions).
By the way, my OS is Ubuntu 16.04 and the Okular's version is 0.24.2. Just for your reference.
First, go to ``Settings --> Configure Shortcuts...''. In the setting window, you could search for the wanted options. I used ``color'' to find the ``Toggle Change Colors'' option as follows:
Choose ``Custom''. When you move your mouse to the ``None'' icon and wait for seconds, it popped out the instruction to add your own shortcut keybindings:
I used ``Ctrl+I'' as the shortcut:
After the setting, you can press ``Ctrl+I'' to toggle between the normal and the inverted color scheme:
I am followingPractical Common Lisp and found there's a so-called Lisp in a Box package, but I decided not to use it now. My plan is to set up a working environment in Ubuntu using more common approaches.
Here are something I have done so far, and they are left here as a note.
Installed Emacs, Slime, and CLisp:
$sudo apt-get install emacs slime clisp
Created ~/.emacs.d/slime/ (to be checked...)
Add ~/.emacs with the content (copied from websites, some functions are not clear to me):
;; MELPA (when (>= emacs-major-version 24) (require 'package) (add-to-list 'package-archives '("melpa" . "http://melpa.org/packages/") t) (package-initialize)) (setq inferior-lisp-program "clisp") ;; Setup load-path, autoloads and your lisp system (add-to-list 'load-path "~/.emacs.d/slime/") (require 'slime-autoloads) ;; Also setup the slime-fancy contrib ;;(add-to-list 'slime-contribs 'slime-fancy) ;;(setq tab-always-indent 'complete) ;;; for auto-complete (require 'auto-complete) (global-auto-complete-mode t) ;(add-to-list 'ac-modes 'lisp-mode) (add-to-list 'completion-styles 'initials t)
After adding MELPA, installedauto-completebyM-x package-install
Also installed evil which enable ``evil-mode'' for Vim-like key strokes
I have built PCL from source and installed it in my Ubuntu 14.04. Everything was fine till these days.
I wanted to rebuild one of my test code in which I used Xition as the input device and it needed OpenNI2. When running ``make'' the system complained that it couldn't find pcl/io/openni2_grabber.h. I checked and found the head file was in the source package but not in the corresponding system folder. So it was something wrong with the make files.
The solution is to turn on the flag BUILD_OPENNI2 which has OFF as the default value[1]. I used
$ grep -r "BUILD_OPENNI2" .
to find it was in the file of CMakeCache.txt. Then just changed the value of from OFF to ON and did make && sudo make install again.
The course had been closed in several months ago, but I didn't get enough leisure time (and proper mood... maybe...) to complete the robot until these weeks. The following photos show the QuickBot:
Front view of my QuickBot
Top view; the BBB is on the left side
The mess of wires between the chassis
What I have done so far is to test the sensors and motors with the help of the testing code qb_test written by Mike Kroutikov. Because I've used the Sharp GP2Y0A41SK0F IR sensors which are different from the ones assigned in the course, I am not sure whether the output is identical to that given in the comment of the test code. Therefore, after some tests, I decided to modify the test code for the IR sensors to show the detected distances in centimetres[3].
I searched and found some conversion formulas for Arduino[2]:
The trend of the output seemed right, but the absolute values were far from accurate. I might have to do some tests to find my own formula.
What I failed in the test was the communication between the host PC (running pysimiam) and the QuickBot's BBB (running quickbot_bbb). I have Wi-Fi adaptor connected to the BBB and it worked perfectly for accessing the internet, but I just couldn't connect the BBB wirelessly from my PC. I decided to postpone this part.
My next plans are:
To write some code to drive the motors with the IR readings as the reference;
Code is available here: https://github.com/hiankun/orb_test
Here was my test on feature matching with ORB. In the video, the target image was shown in the left side and the real-time video was in the up-right corner.
The feature points on the target image matched to the target when there were no other textured objects. If any object has detected feature points, however, the matching relationship would be disturbed significantly.
I have not test the matching approach by using SURF or SIFT features. This will be the next step.
Okay, I know it's not a big deal, but it's my first step to use git more than just a logging tool in local machines.
Actually I was slightly scared by the complexity of git, especially its mystical jargon such as rebase, merge, cherry-pick and so on.
I thought, however, the git shouldn't be just used as a logging tool locally. Also, I wanted to use GitHub as the code repository which would be convenient to people who want to check my code. By upload my code to GitHub, I don't need to copy and paste it in the blog post. That's a better and smarter approach to share source code.
Here are some basic trials in which I tested OpenCV running on my BBB.
The Logitech C920 webcam did some works which I don't know very well so that the loading on the BBB has been reduced significantly. Other webcams might too ``slow'' for the test program to run directly (I remember the terminal returned `select timeout' errors).
[NOTE: the following videos were boring and showed nothing exciting... :-p] [Sorry for the small view of the videos. I will find how to enlarge them later...]
[I've uploaded the video clips so that you can view them with better resolution.]
The first one was the result shown via VNC. The image stream was laggy, but the processing time showed it was about 100 to 200 ms.
The second one showed the result without cv::imshow() via VNC. The processing time seemed reduced, but not significantly.
The last one showed the result without cv::imshow() via ssh. The processing time was no more than 100ms.
It seemed that the VNC costed most of the computing resource.
[A brief note for my first test with the Debian image]
Actually I installed the Debian image several days ago, and did set the Wifi connection successfully. When I tried to update the system, however, the terminal replied with error message said that my system had no enough space. So I went back to Angstrom. And now I'm back to Debian again.
The Debian image was large. After the installation, I checked the disk usage by typing ``df -h''... 93% used... It's crazy.
So, after reflash the on-board eMMC of BBB, I removed something like /usr/share/doc, Chromium, and even Vim (there's vi for later usage). This time, the system updated without errors.
Step 1: Make sure the system know the Wifi adaptor. Use ``lsusb'' and the system return the detected devices. In my case, it's the line with ``Ralink Technology, Corp.''
Step 2: Check ``/etc/rcn-ee.conf'' and make sure it contain the following settings:
Step 3: Edit ``/etc/network/interfaces'' with the following settings:
auto ra0 iface ra0 inet dhcp wpa-ssid your_network_name wpa-psk your_hashed_password
Yesterday when I was trying to update the OpenCV in my BBB, a strange thing happened. After downloading and unzipping OpenCV 2.4.9 in BBB [1], I couldn't log into my BBB via ssh (but using the webpage still worked). The terminal responded nothing, and it just hanged there without logging in.
The Cloud9 IDE helped in the test. It connect to your BBB and allow you to do something with JavaScript (I tested two of them which will be listed below).
Then I tested the second script [3]. After running that script I logged in BBB via ssh again.
Actually I still have no idea what'd happened. Maybe the resource of BBB had been run out after the downloading of OpenCV? Maybe something else caused the problem.
---
Edit:
I read the mail list again and found the post which listed the second script had said something may be useful. It talked about systemd-journal settings.
---
[1] I wouldn't do it again. At the beginning, I was planning to build OpenCV 2.4.9 in my BBB. Later, I read VAT's article and knew that I should use cross-compilation.
After installing the patched fonts, you can add the following settings in the .vimrc to enable the symbols:
if !exists('g:airline_symbols') let g:airline_symbols = {} endif " unicode symbols let g:airline_left_sep = '»' let g:airline_left_sep = '▶' let g:airline_right_sep = '«' let g:airline_right_sep = '◀' let g:airline_symbols.linenr = '␊' let g:airline_symbols.linenr = '' let g:airline_symbols.linenr = '¶' let g:airline_symbols.branch = '⎇' let g:airline_symbols.paste = 'ρ' let g:airline_symbols.paste = 'Þ' let g:airline_symbols.paste = '∥' let g:airline_symbols.whitespace = 'Ξ' set guifont=DejaVu\ Sans\ Mono\ 10 let g:airline_powerline_fonts = 1
Several months ago, I've followed the course of ``Control of Mobile Robots'' on Coursera. Although I've finished the course, but the hardware part has been postponed for these months.
I determined to record the tests on the hardware, and here is the first post on the topic.
The following procedure based on the course lecture.
Step 0: I used my mobile phone as the Wifi hotspot for the BBB internet connection.
Step 1: Connect the USB cable between the BBB and the PC. Plug the Wifi adaptor as well.
Step 2: Log in BBB using ssh. Just type the follows in the terminal of host PC:
ssh 192.168.7.2 -l root
Step 3: (from now on, all the commands will be working in BBB) Use the following command to get the hashed string which will be pasted in the configuration file:
wpa_passphrase "your network name here" 'your password here'
Step 4: Paste the hashed string into /var/lib/connman/wifi.config. The content of the wifi.config looks like:
[service_home]
Type = wifi
AutoConnect = true
Favorite = true
Name = your network name
Passphrase = your hashed password
Update:
I have encountered problems in the Wifi connection when I reflash my eMMC with new Angstrom images. I tried the newest version (2013.09.04) and an old one, but got no luck.
The newer Angstrom could identify the Wifi adaptor (by using lsusb, the terminal returned a message with the Wifi adaptor's company name), but all the same settings just couldn't make BBB connecting to the internet.
Note that the WITH_IPP option had been disabled or there would be errors (which I didn't have time to tackle).
I also used lscpu to view my CPU information. Actually I didn't know anything about ``number of hardware threads,'' and I assumed it just equal to the number of CPU multiplied by ``Thread(s) per core.'' I typed ``make -j16'' during the installation.
After the installation, I check the installed version by typing
pkg-config --modversion opencv
and it returned
3.0.0
Also, in ipython, typed the following command to check the installed version:
In [1]: import cv2 In [2]: print cv2.__version__ 3.0.0-dev
That's out of my expectation. I thought the example was under the location of OpenCV 3.0.0, so it should had no problem for me to run the sample code. Another bad news was that the old StereoBM module was also failed.
---
I just tried the ORB example, but the module was also disappeared from the 3.0.0 version.
After reinstall OpenCV 2.4.9, everything was okay. So now I just have no idea where are the missing modules in OpenCV 3.0.0.
I've just installed CrunchBang in VirtualBox two days ago, but the resolution was limited so it cannot fit my monitor properly. After some trials (including some struggles when installing the so-called Guest Additions), I successfully changed the resolution to my need.
But there's some more work to do to make the change permanently. We need to add the following lines (from my own setting) in ``~/.config/openbox/autostart'':
Actually this confused me and I'm not sure about every details. Here I just write down what I've done for your reference.
The first thing I did was to insert the VBoxGuestAdditions.iso image via the GUI (I've selected the iso file before, so it appeared in the list automatically):
Then click the ``Insert Guest Additions CD image...'' or use the following command to mount the image:
mount /dev/sr0 /media/cdrom
Now we can find the ``VBoxLinuxAdditions.run'' script and run it:
In the previous post [1] I've tried the GrabCut function of OpenCV, when I noticed it was time consuming but didn't try to check the exact processing time. But I was still wondering ``how slow'' did GrabCut could be. So, I started to add the clock() function to see the result [2].
Later, I though of that the processing time was greatly affected by the image size, so I searched for functions which could reduce the images for speeding up GrabCut. What I found were cv::pyrDown() and cv::pyrUp() and they've been implemented in my test code (listed below).
#include "opencv2/opencv.hpp"
#include <iostream>
#include <time.h>
using namespace std;
const bool DOWN_SAMPLED = true;
const unsigned int BORDER = 1;
const unsigned int BORDER2 = BORDER + BORDER;
int main( )
{
clock_t tStart_all = clock();
// Open another image
cv::Mat image;
image = cv::imread("sunflower02.jpg");
if(! image.data ) // Check for invalid input
{
cout << "Could not open or find the image" << std::endl ;
return -1;
}
cv::Mat result; // segmentation result (4 possible values)
cv::Mat bgModel,fgModel; // the models (internally used)
if(DOWN_SAMPLED){
// downsample the image
cv::Mat downsampled;
cv::pyrDown(image, downsampled, cv::Size(image.cols/2, image.rows/2));
cv::Rect rectangle(BORDER,BORDER,downsampled.cols-BORDER2,downsampled.rows-BORDER2);
clock_t tStart = clock();
// GrabCut segmentation
cv::grabCut(downsampled, // input image
result, // segmentation result
rectangle,// rectangle containing foreground
bgModel,fgModel, // models
1, // number of iterations
cv::GC_INIT_WITH_RECT); // use rectangle
printf("Time taken by GrabCut with downsampled image: %f s\n", (clock() - tStart)/(double)CLOCKS_PER_SEC);
// Get the pixels marked as likely foreground
cv::compare(result,cv::GC_PR_FGD,result,cv::CMP_EQ);
// upsample the resulting mask
cv::Mat resultUp;
cv::pyrUp(result, resultUp, cv::Size(result.cols*2, result.rows*2));
// Generate output image
cv::Mat foreground(image.size(),CV_8UC3,cv::Scalar(255,255,255));
image.copyTo(foreground,resultUp); // bg pixels not copied
// display original image
cv::namedWindow("Image");
cv::imshow("Image",image);
// display downsampled image
cv::rectangle(downsampled, rectangle, cv::Scalar(255,255,255),1);
cv::namedWindow("Downsampled Image");
cv::imshow("Downsampled Image",downsampled);
// display downsampled mask
cv::namedWindow("Downsampled Mask");
cv::imshow("Downsampled Mask",result);
// display final mask
cv::namedWindow("Final Mask");
cv::imshow("Final Mask",resultUp);
// display result
cv::namedWindow("Segmented Image");
cv::imshow("Segmented Image",foreground);
}
else {
cv::Rect rectangle(BORDER,BORDER,image.cols-BORDER2,image.rows-BORDER2);
clock_t tStart = clock();
// GrabCut segmentation
cv::grabCut(image, // input image
result, // segmentation result
rectangle,// rectangle containing foreground
bgModel,fgModel, // models
1, // number of iterations
cv::GC_INIT_WITH_RECT); // use rectangle
printf("Time taken by GrabCut with original image: %f s\n", (clock() - tStart)/(double)CLOCKS_PER_SEC);
// Get the pixels marked as likely foreground
cv::compare(result,cv::GC_PR_FGD,result,cv::CMP_EQ);
// Generate output image
cv::Mat foreground(image.size(),CV_8UC3,cv::Scalar(255,255,255));
image.copyTo(foreground,result); // bg pixels not copied
// display original image
cv::rectangle(image, rectangle, cv::Scalar(255,255,255),1);
cv::namedWindow("Image");
cv::imshow("Image",image);
// display result
cv::namedWindow("Segmented Image");
cv::imshow("Segmented Image",foreground);
}
printf("Total processing time: %f s\n", (clock() - tStart_all)/(double)CLOCKS_PER_SEC);
cv::waitKey();
return 0;
}
The key idea was to downsample the image for GrabCut and then upsample the result (I thought it was a mask) to the original size. The result showed a remarkable speeding up in both the debug and the release mode.
Here are the output images with the downsampling strategy:
Fig 1. Original image
Fig 2. Downsampled image
Fig 3. Mask obtained by using GrabCut
Fig 4. Upsampled mask
Fig 5. Final result
Here is the result without the downsampling strategy:
Fig 6. GrabCut result without downsampling
Comparing Figure 5 and 6, we can easily notice the differences between the segmented results. When applying the downsampling strategy, some image details were lost and the mask would be different and had rougher edges as well.
Although the downsampling strategy has the drawback of losing image details, the benefit of reducing processing time was significant. The following table lists the processing time obtained by using above code with and without the downsampling strategy.
As mentioned in the previous post, in which I tried the GrabCut by using the OpenCV's library. Because I didn't have libs and dlls for debug mode, so I tried to use CMake to build them for my own usage.
First I went to OpenCV website to download the latest stable version 2.4.6. The source code for Windows were packed in a exe file. Don't worry about it, just download it and click it and the 7zip will extract the whole source package for you. In my case, the extracted folder was named ``opencv''.
Then I lauched CMake GUI, chose the location where the extracted folder was located, and chose the build directory for the building files.
Click the ``Configure'' button and if everything is okay then the ``Generate'' button. In my case, I'd chosen the generator as ``Visual Studio 2005'' (at a certain step I didn't rememberd0, so the generating result contained an OpenCV.sln in the build folder.
The final step was just click the OpenCV.sln to launch the Visual Studio and then Build the project for Debug and Release mode. The products were located in the build/bin and build/lib directories.
I was considering using GrabCut to cut out the target in one of my working project. After testing it using Python, I thought it's necessary to try it in C++ code. Therefore I started to find some example code and picked one for my test [1].
Here is my test code, the sample photo, and the result:
#include "opencv2/opencv.hpp"
#include <iostream>
using namespace cv;
using namespace std;
int main( )
{
// Open another image
Mat image;
image = cv::imread("sunflower02.jpg");
if(! image.data ) // Check for invalid input
{
cout << "Could not open or find the image" << std::endl ;
return -1;
}
// define bounding rectangle
int border = 20;
int border2 = border + border;
cv::Rect rectangle(border,border,image.cols-border2,image.rows-border2);
cv::Mat result; // segmentation result (4 possible values)
cv::Mat bgModel,fgModel; // the models (internally used)
// GrabCut segmentation
cv::grabCut(image, // input image
result, // segmentation result
rectangle,// rectangle containing foreground
bgModel,fgModel, // models
1, // number of iterations
cv::GC_INIT_WITH_RECT); // use rectangle
// Get the pixels marked as likely foreground
cv::compare(result,cv::GC_PR_FGD,result,cv::CMP_EQ);
// Generate output image
cv::Mat foreground(image.size(),CV_8UC3,cv::Scalar(255,255,255));
image.copyTo(foreground,result); // bg pixels not copied
// draw rectangle on original image
cv::rectangle(image, rectangle, cv::Scalar(255,255,255),1);
cv::namedWindow("Image");
cv::imshow("Image",image);
// display result
cv::namedWindow("Segmented Image");
cv::imshow("Segmented Image",foreground);
waitKey();
return 0;
}
The sample photo used in the test
The result of applying GrabCut
During the test, I encountered an old problem to me, which had been some odd runtime bugs for the debug mode when using OpenCV. The solution might be NOT to mix up the debug and release libraries [2].
Oh, by the way, the processing time of the GrabCut was too long (about 2 seconds in the test case), and I thought it's not feasible for realtime applications. Orz
