Wikipedia:Reference desk/Archives/Computing/2012 March 3

From Wikipedia, the free encyclopedia
Computing desk
< March 2 << Feb | March | Apr >> March 4 >
Welcome to the Wikipedia Computing Reference Desk Archives
The page you are currently viewing is an archive page. While you can leave answers for any questions shown below, please ask new questions on one of the current reference desk pages.


March 3[edit]

Keyboard shortcut in Internet Explorer[edit]

Something odd happened a few minutes ago. I went to type the four tildes as my signature and caught some other key (possibly SHIFT-ESC?). It deleted much of what I had typed and I couldn't recover it with CTRL-Z. Why on earth would I want a shortcut to remove paragraphs of what I had written? SHIFT-ESC isn't one of the shortcuts listed in the help. What happened and can I control the keyboard shortcuts in Internet Explorer 9? Astronaut (talk) 10:44, 3 March 2012 (UTC)[reply]

Yes Shift-Esc does what you said... funny one that, I didn't know of it. However Ctrl-Z works for me, and so does Ctrl-Y to redo. I'm usually paranoid after typing a lot in a wiki edit and tend to save the text in notepad before posting, as I've had wikipedia hanging before and it's not a nice feeling to lose your thought patterns. There's probably a way of trapping it with some funky keyboard interrupt utility, but I don't know of a way in Windows. Sandman30s (talk) 18:45, 6 March 2012 (UTC)[reply]

How to read natural earth's maps?[edit]

Hello, I've tried to download the database of natural earth and I got some text files... Does anyone have any software to read those text files? — Preceding unsigned comment added by 87.68.222.18 (talk) 10:51, 3 March 2012 (UTC)[reply]

Maybe the site's own data creation guidelines give a hint on how to use the data. For example, the one I looked at (coral reefs, because it was a small file) contained data that suggests it is a ESRI Shapefile - ie. it a .zip file containing a .prj, .shp, .shx, and .dbf files. Astronaut (talk) 11:35, 3 March 2012 (UTC)[reply]


Kindle Fire...not e-paper[edit]

It was almost a shock to read suddenly on Wiki that Kindle Fire has not got e-paper screen. I was under impression that Kindle ebook necessarily means e-ink as a matter of rule. Well, what it has it then ? The usual LCD like laptops ? Or IPS (whatever that might mean) is something great that makes LCD soft on eyes (like e-paper is) not harsh on eyes, that could not be read without light and could be read in broad daylight (as opposed to typical LCD), or is Fire just a tablet...?  Jon Ascton  (talk) 14:33, 3 March 2012 (UTC)[reply]

Yes, as the article says, the Fire is a tablet computer, not a dedicated eReader. It's meant to compete with the iPad (at least, it's meant to limit the iPad's encroachment onto Kindle territory). It uses the same in-plane switching LCD display technology as the iPad, which is faster and more colourful than eInk, at the expense, as you say, of contrast, daylight-visibility, and battery life. They say IPS and eIPS are much friendly on the battery than older LCD technologies, but it's still not the month or so you supposedly get from a "real" Kindle. -- Finlay McWalterTalk 15:39, 3 March 2012 (UTC)[reply]
Note also that Amazon continues to sell epaper Kindle readers too; they've segmented their product offering, so people to travel a lot, where regular recharging is difficult, can still get the epaper one, and they sell their own tablet for people who mostly use it at home. The also have a Kindle app for iPhone, iPad, Android, Mac, and Windows PC. And they offer an online reader for any connected HTML5 device. -- Finlay McWalterTalk 15:47, 3 March 2012 (UTC)[reply]
The basic Kindles still use e-ink. The Kindle Fire is meant to be an iPad competitor and uses an LCD screen. They happen to be manufactured by the same company, but they're really quite different devices. --Mr.98 (talk) 15:50, 3 March 2012 (UTC)[reply]

Note that eReader and eBooks ≠ eInk. eBooks are simply are really just a couple o different kinds of file types (.pdf and .epub, for example). You can read eBooks on pretty much any device, from smartphones to desktop computers, not just ereader devices. Mingmingla (talk) 21:49, 3 March 2012 (UTC)[reply]

I think Barnes & Noble's Nook Simple Touch runs Android and it uses electrophoretic ink. But I'm sure Android's capabilities are locked down on the Simple Touch. I know that both the bootloader and the boot ROM are locked up, so you can't install a custom kernel or bypass this by patching the bootloader. I know that the Fire's bootloader is not signature checked (search Google for FIREFIREFIRE) and the new Kindles are easier to hack. --Melab±1 01:52, 4 March 2012 (UTC)[reply]

Wikispaces user rights[edit]

Hello. I'm used to editing Wikipedia, but am new to the site Wikispaces. I tried to ask this question on that site's Discussion Forum, but was ignored. Here is my question:

I'm working with a project to create a wiki/forum. I've created it, and have the job of setting it up and organizing it. As such, I have the "user rights" of organizer and creator. The "creator" user right gives me the ability to make other members "organizers" (a higher-level user right) and to demote organizers (the latter is something only creators can do). As part of a mutual agreement, I'm making a small group of other people "organizers," and I'm dropping all of my user rights. Will I still be listed as the creator? If I am eventually made an organizer again, will I get my creator rights back? dci | TALK 19:25, 3 March 2012 (UTC)[reply]

I'm not entirely sure how to answer this question; I did look at the FAQ, but I didn't see anything obvious. I suspect, however, that if you contact them, the Wikispaces support people may be of more help than their forum. But if anyone here knows the answer, obviously that would be more immediately helpful than that link. --NYKevin @967, i.e. 22:12, 3 March 2012 (UTC)[reply]

Bash problem with single quotes[edit]

Hello! I've written a script in GIMP that creates a playing card for a specifed rank and suit. Here's how it can be succesffuly executed from the terminal:

gimp -i -b '(script-fu-playing-card "2" "Sans" 1 0 "/home/me/Pictures/Cards-png/1-2.png")' -b '(gimp-quit 0)'

This produces the 2 of hearts; that is, the rank is a string (the first arg after script-fu-playing-card) and the suit is an integer {1..4} (3rd arg). The problem is that now I'd like to embed this command inside two for loops that iterate over suit and rank, but putting $suit and $rank variables inside that command doesn't return their values because of the single quotes. Removing the single quotes and escaping the double quotes and parentheses returns weird errors like GIMP-Error: Opening '/home/me/"Sans"' failed: No such file or directory. Haven't had luck with escaping everything, even the single quotes. So basically, how can I substitute values for the 2 and 1 in the command above with values in vars $suit and $rank while preserving the single and double quotes necessary for the command's execution (in a terminal in Ubuntu Linux). Thank you very much (this has been a big headache).--el Aprel (facta-facienda) 21:23, 3 March 2012 (UTC)[reply]

Sorry, but it is completely impossible to insert anything other than literal text into single-quotes at the command line. It's even impossible to embed a literal single quote into single quotes. The whole point of single quotes is to prevent the shell from doing any expansion or interpretation of the contents, so that you can be sure the contents you entered are used as-is. You might try using $(echo "'(script-fu-playing-card" "\"$rank\"" '"Sans"' $suit "0 \"/home/.../$suit-$rank.png\")'") instead of '(script-fu-playing-card ...1-2.png")'. Note that the echo command will insert spaces between arguments automatically. And make sure your script is running under bash (check the shebang). --NYKevin @957, i.e. 21:57, 3 March 2012 (UTC)[reply]
I hit similar problems all the time and, while (in my experience) it is usually possible to solve them using a bash script, sometimes it's more trouble than it's worth. I end up creating a text file using emacs and just source that. Emacs is great for this sort of thing. In this case I would start with
  echo {1,2,3,4}{1,2,...,13} > f

and then manipulate f using keyboard macros ('f' is my name for a nonce file). Then ". ./f" sources file f. Works every time, but it is perhaps not an elegant solution. HTH, Robinh (talk) 00:17, 4 March 2012 (UTC)[reply]


If you want to "interpolate" variables into a single-quoted string you can just end the single-quoted string immediately before and restart it after, e.g. '(script-fu-playing-card "'$rank'" "Sans" '$suit' 0 "/home/me/Pictures/Cards-png/'$suit'-'$rank'.png")'. The escaping approach would also have worked except that you forgot to escape the spaces (which are not shell argument separators but rather part of the third argument you're passing to gimp). You need to write \(script-fu-playing-card\ \"$rank\"\ \"Sans\"\ $suit\ 0\ \"/home/me/Pictures/Cards-png/$suit-$rank-2.png\"\), or something like that.
In situations any more complicated than this I would certainly advise using a better programming language than bash, which pretty much sucks for anything complicated enough to need debugging or maintenance. These days you can usually rely on Python or at least Perl being present. -- BenRG (talk) 04:14, 4 March 2012 (UTC)[reply]
(expanded quoting lesson, mostly written before BenRG's reply) If you want to do this without guessing, here's the key: First, understand the command syntax as a sequence of words. Second, decide what you want to put in each word. Last - and I really mean LAST - choose the quoting mechanism(s) to build the words.
The original command consists of 6 words. The first 3 are gimp, -i, and -b and they are simple enough that they don't need quoting. The other -b is also simple.
The last word is (gimp-quit 0) and it needs to be quoted because it contains a space and parentheses. If the space isn't quoted, then this one word would be split into 2 words. If the parentheses aren't quoted, they'll be a syntax error. This word is quoted by adding apostrophes to the beginning and end.
Notice that the quoting apostrophes are not part of the word. They're a piece of shell syntax, not part of the syntax of the gimp command. The word is passed to gimp as a string that is 13 characters long, beginning with the left parenthesis and ending with the right parenthesis.
Other quoting methods would work equally well in this case. You could change the apostrophes to quotation marks, like this
gimp -i -b '...' -b "(gimp-quit 0)"
or remove the apostrophes and quote each special character individually with a backslash, like this
gimp -i -b '...' -b \(gimp-quit\ 0\)
and gimp couldn't possibly tell the difference because the word that results from the quoting is identical.
Now we come to the hard part. The longest word in the original command, also quoted with apostrophes, contains not just spaces and parentheses but also quotation marks, and you want to add variable expansions to it. The biggest obstacle to doing this correctly is trying to somehow fit your answer into the pre-existing pair of apostrophes that surround the word, as if they were a non-negotiable piece of syntax for gimp itself. Instead look at them instead as part of shell syntax, which they actually are (gimp never sees them), and understand that the different styles of quoting are different ways of expressing the same thing, and solutions will suggest themselves.
The simplest (and ugliest) is to do the backslash thing. Drop the apostrophes and put a backslash before every special character in the word, then you can throw in a variable expansion anywhere you want. Like this
rank=2 ; suit=1 ; gimp -i -b \(script-fu-playing-card\ \"$rank\"\ \"Sans\"\ $suit\ 0\ \"/home/me/Pictures/Cards-png/1-2.png\"\) -b '(gimp-quit 0)'
That's unpleasant, so you'll be looking for something better. Replacing the apostrophes with quotation marks is also possible, and it will enable variable expansion. The side effect is that you'll have to put a backslash before each quotation mark in the word itself. There are 6 of them, which is still a lot of backslashes, but less than before:
rank=2 ; suit=1 ; gimp -i -b "(script-fu-playing-card \"$rank\" \"Sans\" $suit 0 \"/home/me/Pictures/Cards-png/1-2.png\")" -b '(gimp-quit 0)'
That's tolerable, but there's an even better way which will get rid of all the backslashes. You only need to realize that different kinds of quoted and unquoted strings can be combined to form a single word. For example, these commands have the same effect:
echo '((foo))'
echo '('"("foo\)')'
In both cases the characters that need to be quoted are quoted. In the first case, the letters are also quoted. In the second case they're not. That makes no difference because letters aren't special so quoting them has no effect. The result is the 7-character word ((foo)). This sort of mixed quoting can be applied to produce a word that is mostly inside apostrophes but has a few unquoted pieces with variable expansions in them, like this
rank=2 ; suit=1 ; gimp -i -b '(script-fu-playing-card "'$rank'" "Sans" '$suit' 0 "/home/me/Pictures/Cards-png/1-2.png")' -b '(gimp-quit 0)'
The shell builds the big word from these pieces:
  1. '(script-fu-playing-card "'
  2. $rank
  3. '" "Sans" '
  4. $suit
  5. ' 0 "/home/me/Pictures/Cards-png/1-2.png")'
All the spaces and quotation marks are inside the apostrophe-quoted pieces, so they survive to become part of the word, and the variable expansions are unquoted so they work. After variable expansion, the pieces are put back together. One last improvement is to enclose the variable expansions themselves in quotation marks. If you don't, then when the variable's value contains a space, the word gets split. It won't happen here since rank and suit don't contain spaces, but it's a good habit. Doing that, and adding the loops, I get this:
for rank in A 2 3 4 5 6 7 8 9 10 J Q K; do
  for suit in 1 2 3 4; do
    gimp -i -b '(script-fu-playing-card "'"$rank"'" "Sans" '"$suit"' 0 "/home/me/Pictures/Cards-png/1-2.png")' -b '(gimp-quit 0)'
  done
done
68.60.252.82 (talk) 04:55, 4 March 2012 (UTC)[reply]
I am Stephan Schulz, and I approve this answer! Very well explained! --Stephan Schulz (talk) 09:04, 4 March 2012 (UTC)[reply]
Thank you all for your excellent responses, especially from 68.60.252.82. Once I understood how bash processes the words, as explained above, it made a lot more sense. This will be an indispensible reference for whenever I run into another bash problem, as well.--el Aprel (facta-facienda) 20:02, 4 March 2012 (UTC)[reply]

.m2ts[edit]

The .m2ts file, I'm told is the highest quality of Codec that a video can currently be on a computer. Is this correct? I know it depends on the bitrate/second and the highest the .m2ts has is in the 30,000's. Can anyone else explain this properly to me?Zaltaire (talk) 23:09, 3 March 2012 (UTC)[reply]

Well, it would help to define 'quality', but the answer is mu. .m2ts is a container format, not a codec. Additionally, bitrate is just a heuristic. Cleverer encodings can achieve better fidelity (again, appropriately defined as e.g. perceptual PSNR) reproductions of source data at smaller filesizes, but potentially at the cost of greatly increased complexity of encoder and/or decoder. However, the reason it is a heuristic is that higher birate means having more 'space' in which to store your approximation to the source material. All else being equal, this should mean your encoding can be more faithful to the source. As for the 'highest quality' of codec, if we take this to pertain only to fidelity of reproduction, then this would have to be some lossless codec - however impractical it might be for general use. 131.111.255.9 (talk) —Preceding undated comment added 02:12, 4 March 2012 (UTC).[reply]
I don't know about this codec specifically, but I doubt if any codec is universally better quality for all types of video. Cartoons might have one best, slide shows another, etc. StuRat (talk) 01:56, 4 March 2012 (UTC)[reply]
The highest quality would be a "raw" video stream with no compression. No compression artifacts would be introduced whatsoever. (Quibble: "codec" stands for "compressor/decompressor", so technically a codec with no compression is a misnomer ... but a "raw" codec would be called a "raw codec" anyway, so I'll let it stand!) Comet Tuttle (talk) 02:06, 4 March 2012 (UTC)[reply]
Here (full paper, summary) is a comparison between different lossless video codecs, which concludes:
  • In Video Capture and Video Editing Area the overall clear winner is Lagarith.
  • In Maximum Compression area the overall winner is YULS.
  • The most balanced and flexible codec is FFV1: relatively good speed and high compression for various presets.
--NorwegianBlue talk 07:58, 4 March 2012 (UTC)[reply]
Before video data reaches the first codec, information has already been lost. Video data undergoes color space conversion, introducing rounding-error and clipping. Next, it undergoes chroma subsampling, because most codec algorithms (including lossless codecs) expect data in this format. So, "lossless" really only refers to data preservation by the codec, but does not mean "bit-identical" to the source data. A modern digital camera, or video software system, has a sophisticated media graph. If you would like to learn about how codecs fit into this picture, I recommend investigating GStreamer, a free software media and video pipeline. It will be a bit of a technical deep-dive to get into its source, available on GStreamer's website; but it will help orient you to the many stages of the software and hardware pipelines that take video frames from "somewhere" and put them on your screen. Codecs are only a small part of the story! On modern systems, high-quality video playback is one of the most demanding tasks your computer is asked to do - so you really should compare end-to-end quality, rather than codec bit-accuracy. If a codec stalls the pipeline to improve quality, you may lose audio synchronization, drop frames, or corrupt the image elsewhere. So, beware of claims by codec engineers - especially claims of bit accuracy - if they are uncaveated by engineering realities! Nimur (talk) 17:38, 4 March 2012 (UTC)[reply]
This surely depends on your intended purpose. If you are storing the video for immediate playback then you do have to worry about dropped frames. If you are storing the video for archival purposes or as an intermediate during editing, then dropped frames should not be something you have to worry about unless the system is incredibly flawed since it should not require real time performance and therefore should not be dropping frames. (Performance does matter, if it takes you 1 minute to decode a frame editing is likely to become unfeasible.) Of course in the archival case, it probably doesn't make sense to convert to a lossless format if your source data is already compressed and you are not doing any editing unless perhaps your source data is in a format you consider unsuitable for archival, e.g. a proprietary closed source format so you do need to convert to some format.
BTW, perhaps I'm mistaken but I was under the impression many lossless codecs do infact support Y'UV444 (i.e. no chroma subsampling is required). I believe some also support RGB, so colour space conversion may not be needed. (Remember this surely depends on your source data. If your source data is YCbCr, then you may not want to store it as RGB. Even if it was RGB sometime early on, if you don't have access to that data, it's a moot point to you.) Of course you may eventually need chroma subsampling and colour space conversion, precisely when in the process you should do that is something you need to consider.
Also from my experience, many lossless codec developers/engineers do understand these sort of things, however they do expect their users to already understand them as well so don't bother to offer explainations. I don't think it's really the fault of engineers if people use their codecs without understanding what they are doing. (Although realisticly, I expect most people considering lossless video compression who don't know what they are doing will quickly change their minds when they realise the bitrate needed. The bigger problem is people encoding video with lossy compression with perhaps excessively high bitrate and other such things.)
Nil Einne (talk) 04:09, 6 March 2012 (UTC)[reply]