Twenty-Twelve (Twe-Twe..), year of the surprised lion. Actually in terms of zodiac years it’s apparently time for a dragon. Big roaring, fire breathing lizard thing.
|
Twenty-Twelve (Twe-Twe..), year of the surprised lion. Actually in terms of zodiac years it’s apparently time for a dragon. Big roaring, fire breathing lizard thing. The most recent release of the Opera web browser seems to have taken a strange turn. As expected, there are two text boxes, the address bar, and the search box. In Opera, you can set keywords for your search engines, which allows you to search using a specific engine from the address bar, e.g.
In versions prior to 11.60, depending on what options were selected, the address bar would provide results from your history and/or bookmarks as you typed, an incredibly useful feature. In version 11.60, that still happens. In addition to that, it will no longer wait for a keyword, anything typed starts bringing in suggestions from the default search engine, Google in this case. If that wasn’t an annoying enough feature on its own, Opera then places these results above the bookmark/history results. I can no longer type three or so characters, hit down a couple of times and have the bookmark I wanted, I have to wade through a pile of search suggestions I have no interest in.
One solution was to disable search suggestions entirely. This leaves keyword searches and search box searches similarly affected, so not terribly useful. Another was to add a dummy search engine so there can’t be suggestions. Although this requires it to be set as the default one, adding an extra step to getting suggestions in the search box (changing the selected search engine to, say, Google before typing the query). The fix I’m currently using is to disable “Address Bar Content Search” in the advanced configuration. Remember to click save and restart the browser after though. It seems to do the trick, thanks go to artmil over in the Opera forums Ah, so close. This still isn’t perfect. Here are some screenshots of my address bar. It remembered that I wanted search suggestions and is now going to forcefully display them however irrelevant they are in regards to what I’m typing, for as long as I keep this tab.
In my last post there was some Java code for bundling up PDF files. In this post, it’s back! This time with the focus being on the comparison method of the filenames. The problem with the default sort is that a number will always be ranked higher than a letter. The files I’m trying to join are named hierarchically, like this:
There are title pages for categories and subcategories, and information pages for items within those categories. The problem with standard naming and the naming of these files can be demonstrated by the position of the highlighted item ‘lemon’. It is a direct descendant of Page 1.1. Yet It ends up positioned behind the subcategories because it ceases to have a numeric name. This is the updated Merge.java file that forces letters to come before numbers, yet still keep them sorted correctly within themselves.
which sorts such that I get a list like this:
The need to create a variety of similar pages in a PDF file recently came about. Once again unique, once again related to d-touch. When such pages require rotated text, it becomes a whole new level of fun sorting out the co-ordinates and bounds. A different approach seemed necessary and I found myself thinking how nice a template would be, just search and replace. Then it hit me: SVGs. Images in XML, with support for including actual images and text at any angle, size or position. Perfect. Graphically creating a first draft of the template took minutes. The other benefit of using a graphical template is how easy it is to change the design and re-run the data through. 215 SVG files don’t quite leap into a PDF on their own though, and the two image packages I intended to use rather failed to manage. One slowly loaded each and every one before giving an error refusing to accept them as images, the other was quite happy they were valid images for merging to PDF but didn’t do anything after I pressed go. I had manual options available I wasn’t about to jump at, such as saving each one as a PDF and using BullZip PDF Printer or similar to merge them slowly by hand. The surprisingly simple and fast solution turned out to be Java. Running the Rasteriser from the Batik SVG Toolkit on the folder of the SVGs returned a folder of PDFs, a step closer but not quite there yet. java -jar batik-rasterizer.jar -m application/pdf -w 2480 -h 3508 -d folderForPDFs folderOfSVGs\*.svg The final step was to write a small Java wrapper for the PDF Merger Utility from the PDFBox package. This basically consisted of scanning the directory of single page PDF files, adding each one as a source for the Merger, and running it.
Yes, that is a generic catch everything that goes wrong block. No, you shouldn’t use them :P To compile that you’ll be needing to use something like this javac -cp pdfbox-1.6.0.jar Merge.java And something like this to run it java -cp .;pdfbox-1.6.0.jar;commons-logging-1.1.1.jar Merge folderOfPDFs outputName Otherwise known as a way of combining a ton of photos of the same area to pull out only the static content. It's one of the least time consuming ways to get impossible photos of empty streets. Basically you take 40 or so photos of a busy section of road without moving the camera even slightly (aligning the images takes somewhat more code, and levels of computer vision that I don't want to go into right now). It is unlikely that any of these photos will show the entire road with no traffic in sight, but if you look at a single particular pixel in every one of those photos, it is very likely that the most common value for it will be 'road'. Ideally, you just select that most common value for each pixel and ignore everything else. In practice, cameras and images don't store or detect the exact colour of an object, and each pixel of it will vary per photo, so taking a pure mode is out as an average for that reason - there will be no reliable most common colour to select. To get around this, the mode would have to be of ranges. Either way, to use the mode every single image has to be considered for each pixel. Depending on the number of images this can lead to awful memory use as every image has to be held available, or huge amounts of disk access as groups of pixels are read in every so often. Breaking the images into groups and taking the mode of each before repeating for those new temporary images would be a loss of accuracy but help solve the above problems. The arithmetic mean is wonderful for computation and is what I'm currently using. Two images can be read in, averaged, and stored as a temporary image, a third image can be read in (replacing the second), averaged with the temporary image, then stored so as to replace it, and so on. Only two images are in memory at any one time. Unfortunately there may be an increased number of rounding errors depending on how the values are stored. Another problem is that unlike the mode, everything gets a place in the final image - one bright red car on a black road will require a large number of images without a car in that place in order to average back down to an invisible level, whereas using mode, it would have been left out completely. The CodeThis is a piece of C++ code that uses the arithmetic mean and Qt (if you want to compile it you'll need to build a basic Qt framework around it). For images I recommend non-streaming webcams pointing at roads or highstreets. // temporal averaging // zoril.co.uk // 07/Nov/2011 // we only need two images QImage im_base; QImage im_loaded; // files need to be sequentially numbered int num = 1; // load images matching the name in the text field // e.g. current?.jpg // => current1.jpg // => current2.jpg // => current3.jpg // => ... // first image used for dimensions im_base.load(ui->filepattern_fld->text().replace("?", QString::number(num))); // set dimensions int w = im_base.width(); int h = im_base.height(); // all the time an image loads while(im_loaded.load(ui->filepattern_fld->text().replace("?", QString::number(num+1)))) { // loop through every pixel for(int x = 0; x < w; x++) { for(int y = 0; y < h; y++) { // get the current average colour uint px_base = im_base.pixel(x ,y); // and the new colour uint px_loaded = im_loaded.pixel(x, y); // break into components and take (cumulative moving) average uint red = (((px_loaded >> 16) & 0xFF) + num*((px_base >> 16) & 0xFF)) / (num+1); uint gre = (((px_loaded >> 8) & 0xFF) + num*((px_base >> 8) & 0xFF)) / (num+1); uint blu = (((px_loaded ) & 0xFF) + num*((px_base ) & 0xFF)) / (num+1); // make into colour QRgb newpx = qRgb(red, gre, blu); // store to averaged image im_base.setPixel(x, y, newpx); } } // move onto next image num++; } // save image im_base.save("output.jpg"); red, gre and blu would probably be better off not forced into ints and stored in a virtual image each loop. The Original ImagesThe Resulting ImageThis image was generated using 17 source images (from a webcam) and the arithmetic mean. ![]() Temporally Averaged from 17 Images Using 70 Images![]() Temporally Averaged from 70 Images I shall update this if I find a way to have some form of weighted average. I'm thinking.. read in x images, find some form of average, and then base further inclusion on deviation from that. |
|||||
|
Copyright © Zoril.co.uk 2006-2012 - All Rights Reserved |
|||||