Computing desk
< May 9	<< Apr \| May \| Jun >>	May 11 >

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.

May 10[edit]

MP4[edit]

Windows Media Player won't let me play .mp4 files! So, does anyone know where I can download the codec needed to play my files on WMP? (I have Winamp as well but WMP is my preference ...) And one more thing: I don't want to download a giant codec package, only the one necessary for what I'm doing. Thanks! --Yellow1996 (talk) 00:10, 10 May 2013 (UTC)[reply]

".mp4" is a file extension, and by itself conveys no information. It usually implies that the file conforms to the MPEG 4 container format. Even that still isn't enough information to determine the codec of the file. (Often, the file extension additionally implies that the codec is MPEG 4 Part 10, or, "H.264" - but this is not universally true).

In my experience, I have found ffdshow (a Windows DirectShow plug-in for ffmpeg) to be the best all-around way to get most video files to play on Windows. It is a port of libavcodec, a free and open source library that implements the H.264 standard, as well as other common standard codecs. Nimur (talk) 01:42, 10 May 2013 (UTC)[reply]

I’d go with VLC media player if I were stuck on Windows. ¦ Reisio (talk) 07:03, 10 May 2013 (UTC)[reply]

Seconded. However, VLC does seem to have trouble with some files that the native Windows Media Player seems able to handle. I don't know if it's caused by improper coding or oddball codecs, but I keep both programs on hand for use; I can't trust either one 100%. 64.235.97.146 (talk) 19:58, 10 May 2013 (UTC)[reply]

Problem solved. Thanks, everyone! :) --Yellow1996 (talk) 01:46, 11 May 2013 (UTC)[reply]

RetroUI problems[edit]

I've been having a problem since I added RetroUI to my Windows 8 computer (I'm 5 days into the 7-day trial). After I boot, after the desktop appears, it takes a long time until I can use the computer. The mouse is not there, etc. The amount of time from when the desktop appears until I get control of the computer varies a lot, but I've measured it at up to 110 seconds. The RetroUI tech support thought that something was keeping it from starting. I'm using Avast and Malware Bytes, and I added everything in the RetroUI folder to the exclusion lists, and I still have the problem.

Does anyone have an idea about how to fix this? Bubba73 ^{You talkin' to me?} 05:38, 10 May 2013 (UTC)[reply]

Uninstall it and switch to Classic Shell; or better yet, switch to an altogether more sane OS. ¦ Reisio (talk) 07:01, 10 May 2013 (UTC)[reply]

I had been using Classic Shell before RetroUI. I think RetroUI is better, excpt for this startup problem. Bubba73 ^{You talkin' to me?} 14:59, 10 May 2013 (UTC)[reply]

One thing to be aware of with programs like RetroUI is that a lot of what they are doing is not based on any of the publicly documented APIs supported by Microsoft. This means that they're probably based on experimentation and assumptions of how things work in the OS rather than official facts stated by Microsoft. This can lead to unusual and hard-to-reproduce bugs when the software is run in the unique environment of systems other than the ones it was developed on. Microsoft is planning on releasing an update to Windows 8 before the end of the year that they claim will address a lot of the complaints. If you're still not happy with it then, there is always the option of downgrading to Windows 7. Right now it is selling for about $90 on Amazon in the US - a lot more than the $5 for RetroUI, but it also gets you back to the proper version of the interface RetroUI is trying to reproduce. 38.111.64.107 (talk) 18:59, 10 May 2013 (UTC)[reply]

I upgraded this computer from Win 7 to Win 8. I had the option of going back, but I decided not to. Bubba73 ^{You talkin' to me?} 23:56, 10 May 2013 (UTC)[reply]

Is there any good, easy way to do nominally GUI-oriented stuff in Windows?[edit]

I was surprised to find out that Ruby uses Tcl/Tk to do Windows GUI stuff. Why is a fancy language like this that aspires to have everything predefined by convention not offering its own simple set of commands to interface with the OS directly? More to the point, are there easy options in other languages (Lua, Perl) for basic navigation? For example:

I want to drag a file and drop it on some icon and have my script run, and have it receive as parameter(s) the name and location of the file dragged onto it.

I want to have an icon for Command that I can copy into that directory that opens in that directory, no CD required.

I want to have a function as simple to use as print() for a Lua program that can take a string of text and uses it to display/conceal/resize windows or add buttons, content, etc. into them as simply as you'd add a return with "/n".

Am I just clueless about options for stuff like this, or is there some huge cluster fuck in windows that is preventing people from making basic stuff like this, or has no programmer ever seen a need for any of these things? Wnt (talk) 13:03, 10 May 2013 (UTC)[reply]

I really don't understand your question at all. If you're asking "why does Ruby use a clunky old thing like Tk rather than Windows' own GUI framework", well I think that's because with Tk is particularly easy to get something basic working with just a few commands. The real Windows GUI is available to all programs, and all programming languages, from DLL files. It's certainly possible to write old-style win32 GUI programs in other languages (I've done this with win32gui in Python), but that's a tiresomely low-level API, so writing programs is a bit of a chore. Programs can also use higher level (which can mean less flexible) frameworks like WinForms (I've got a python program somewhere that does that too). These, and other APIs like Direct X are available to everyone - as a practical matter, someone usually has to write a little translation shim that bridges the gap between that language's data model and the native API (which are usually exported by DLLs using Microsoft's own x86 calling conventions). Other programs (e.g. Wireshark, Audacity) eschew the native API (which, after all, confines them to running only on Windows) and use cross-platform GUI toolkits like Swing (for Java), GTK, Qt, Tk, or WxWindows - these allow the same program to be compiled, with little change, on Windows, MacOS, Linux, etc. - at the expense of the resulting program looking slightly alien on every platform. But if your question really is just "GUI programming seems unduly complicated, tiresome, and obscurant", then yes, it is. GUIs are powerful, complex, concurrent, asynchronous, and graphical, so it's inevitable that programming one is going to be much harder than a simple interrogative textual Q&A. -- Finlay McWalterჷTalk 14:16, 10 May 2013 (UTC)[reply]

I'm getting the point that Tcl/Tk (and others) give a platform-independent GUI, but I still don't really understand why other languages wouldn't include these features directly, in an equally platform-independent way, and hopefully invent some new philosophies about how to make them better. Wnt (talk) 19:48, 10 May 2013 (UTC)[reply]

Tcl is beside the point - Ruby does not use Tcl. Ruby uses Tk, but can use other GUI frameworks too, and other languages can use Tk. You should not impute a particular preference in Ruby for Tk - its bundling is just a matter of convenience. Languages have to do lots of different things, and reimplementing their own way of doing everything, rather than using what's available on the system already, is often foolishness. GUIs are no different - language developers have enough work to do just developing their language and the core stuff that they can't get elsewhere. So they use existing GUI frameworks, either platform specific or multi-platform, to get stuff done. Strong coupling between a language and a GUI framework is usually a way to make a weak language and a weak GUI. Sometimes, as with Java's AWT or Swing, language developers have reluctantly had to also develop a GUI in parallel (particularly back in the 1990s when AWT and Swing were born), often because there wasn't a suitable multiplatform GUI that met their requirements. These days GTK and Qt in particular are very mature, and it is difficult to see why some language should reinvent those very fine wheels. Don't think that including stuff into a language "directly" is a good thing; it is usually not, and wise language designers try to keep their languages as small, and as task-directed, as possible. -- Finlay McWalterჷTalk 20:17, 10 May 2013 (UTC)[reply]

Possibly the easiest (and thus least flexible) way of doing very basic GUI tasks is Zenity which allows shell scripts to do some very basic dialog box ("do you want to wipe the disk?") type things. The practical utility of this on Windows is somewhat questionable - it does allow cmd.exe scripts some semblance of a a GUI, but working in that antediluvian horror is such a bother that GUIs are the least of someone's worries. Once someone migrated to Windows Powershell, which passes for a sane, modern shell, they get direct access to DLLs, and might as well just make Winforms calls like this. -- Finlay McWalterჷTalk 14:39, 10 May 2013 (UTC)[reply]

bokeh enhancement[edit]

artificial bokeh where there isn't any is probably the worst thing ever, say you have an image with bokeh and existing blur. Is there an algorithm to detect how blurred a part of an image is, and based on that, add existing blur? Can you turn an 85 f/2.8 image to an 85 f/1.4 image for instance? 137.54.31.42 (talk) 14:18, 10 May 2013 (UTC)[reply]

There is no such thing as "I' am aware of artificial bokeh" when it depends on your lens. You, as a photographer have full control - if you know how. Can you turn an 85 f/2.8 image to an 85 f/1.4 image for instance? No. --Aspro (talk) 18:08, 10 May 2013 (UTC)[reply]

Bokeh can be modeled as a point spread function whose parameters depend on distance to the camera aperture. You can in principle create an estimation algorithm to determine depth, and calculate an appropriate point-spread for that point, and then convolve the PSF with your input image. If you've followed the details, you will recognize this as an adaptive nonlinear filter; in other words, for a seemingly-simple task, you will need to run right up against the state-of-the-art in the mathematical theory and practice of signal processing.

Keep in mind that when you change the aperture size, you are not only changing depth of field (and therefore, the magnitude of the visual appearance of the bokeh); but you are also changing the total light collected; the focal properties of the lens; and you are potentially exposing more imperfections of the image-capture system. It is not sufficient to model the change in the PSF alone.

Here's a fun slide-deck from a 2008 conference, Modeling and Synthesis of Aperture Effects in Cameras. Nimur (talk) 18:23, 10 May 2013 (UTC)[reply]

what is innermetrix?[edit]

I just found innermetrix on my computer. What is it? Where did it come from and How did it get on my computer? How do I remove it?173.21.123.164 (talk) 17:44, 10 May 2013 (UTC)[reply]

Innermetrix is a firm of management consultants, and I can't find any other references to the word immediately. Are you sure that's the right spelling? Tevildo (talk) 18:33, 10 May 2013 (UTC)[reply]

Yeah I also did a search with different keywords and only turned up that site. Is it a program? Where did you find it? --Yellow1996 (talk) 02:47, 11 May 2013 (UTC)[reply]