A sturdy socket, and a 3D printer. While highly dexterous neurally controlled arms and hands are in development, they're far from an off-the-shelf option. For specific uses (e.g. holding various artists tools) you may well be better off with some sort of magnetic socket on a stump cup, and a rack of special purpose end manipulators for each tool.
Boot-to-desktop, and some way to categorise/group the tiles on the start screen. I don't really want a return to the 'program-in-a-folder-in-a-folder with piles of uninstall, manuals, help files, tutorials, demos, etc links lying about the tree at random' approach of the start menu, but some sort of organisation beyond just vaguely dragging things about would be nice.
What you are describing is called 'motion interpolation' It is a fundamental part of the last few generations of video CODEC, and the current crop of commonly in-use CODECs (h.264, VP8, ASP) all implement it.
The big problem with 'magic' video enhancers is that mathematically, CODECs are already very, very good at identifying easy to optimise bits of video, so anything your algorithm does is either totally redundant, or just makes things harder to compress (and thus lower quality at the same bitrate, or the same quality requiring a higher bitrate). Identifying what looks good to the human eye, however, is something much harder to do algorithmically. x.264's psy-optimisation was worked out more through iterative trial-and-error than any sort of mathematical system (hence why encoding to optimal PSNR or SSIM is pretty stupid if a human is going to be watching the end-video).
I've seen a whole lot of video enhancement 'algorithms', boxes, programs, etc. Not one of the press-button-get-video variants have actually improved video quality, and almost universally they just make things worse; more often than not, they just shove up contrast and saturation and add an unsharp mask, but some are genuinely innovative in their uglyness (e.g. the dreaded WarpSharp, Q-Tec's BD butchery, etc). The vast majority of 'easy to use' variants, with a few sliders to move about or checkboxes to flip, are equally ineffective.
Do you have any examples of your 'algorithm' that show it to be something other than run-of-the-mill?
Running on something other than H2 outside the lab is a breakthrough You can't rely on your cryogenic fuel to cool your engine, you need to build a chamber that will handle massive shockwaves at hilarious temperatures.
The Intercooler operates on a Helium loop, but the loop is closed: it is the Hydrogen fuel that provides the cooling, and no Helium is lost in operation. Additionally, the Intercooler, the hardest part of the engine, has been tested successfully. The rest is running turbines and a rocket on H2, which has been done numerous times in the past.
The big barrier is that it doesn't scale down well at all: you can't built a small vehicle that you can actually use for launching anything, you have to stump up the cash to build the full thing if you want any sort of return on investment.
And since pretty much everyone owns 'fire & forget' missiles that identify, discriminate, lock on and home into targets under on-board terminal guidance, why would anyone want to ban autonomous lethal robots? They've owned and operated them (in anger!) for decades.
Or just kill the damn javascript and use whatever buttons or context menus you want. Just use this bookmerklet:
javascript:(function()%20{%20function%20R(a){ona%20=%20%22on%22+a;%20if(window.addEventListener)%20window.addEventListener(a,%20function%20(e)%20{%20for(var%20n=e.originalTarget;%20n;%20n=n.parentNode)%20n[ona]=null;%20},%20true);%20window[ona]=null;%20document[ona]=null;%20if(document.body)%20document.body[ona]=null;%20}%20R(%22contextmenu%22);%20R(%22click%22);%20R(%22mousedown%22);%20R(%22mouseup%22);%20})()
I thought this was standard operating procedure for any game these days.
I think the difference is between "movie/TV show ostensibly set in vaguely the same universe, and maybe we'll throw in a character or two with the same name" and using stories that actually happened involving player actions.
I'd really like to see one of the many EVE heists play out. There are remarkably few sci-fi heist stories about (the only ones that comes to mind are an episode or two of Firefly, and "Saturday Night and Sunday Morning – CASH EYE", but that was an Oceans Eleven homage).
For page turning, you can definitely use a Kindle with only one hand. If held from the back, you can easily hit the buttons on either side with either your thumb or fingertips. If held folio-style, you can press the page-turn buttons of whichever side you are holding with the flesh of your palm.
It's a micro-display module, small field-of-view, and look-through. It's not exactly ground-breaking technology, and essentially equivalent modules have been on sale for the past couple of decades for anyone willing to actually buy one (and, until the last decade, can afford research/military pricing). Those tiny DLP chips and miniature LCDs used in projectors? They aren't found just in projectors.
With the exception of the omitted cellular modem and amplifiers, and the different display, the components running Google Glass are the same as you'll find in any number of smartphones. $1500 is what they're selling for now (or rather, sold for while available), as a development kit. If they intend to go full-scale, then volume production will further reduce part and manufacturing costs.
Sure, a touch-screen is nicer than a 4-way pad for selecting menu items, but I bought an e-reader to read books, not navigate menus. This is also my beef with the Kindle Touch/Paperwhite/whatever the non low-end models are called now. The basic bog-standard kindle, I can pick it up and hold it while reading without worrying if I'm about to accidentally turn a page, change the font size, exit my book, etc.
I did briefly own Kobo's lower end model for about 2 days before returning it. That one did have buttons, but you also had to go and make a cup of tea between every page turn. Kobo no longer even sell that model, or any others with page-turn buttons.
Only if all fingers are currently present and visible, or all have been present (and externally identified, either using manual calibration or an additional camera and some sort of classifier) at once and the remaining fingers have been continuously visible since (no occlusions), and the hand has not changed orientation. Forming a fist and then extending a single finger would prevent identification.
it would be possible for the device to identify exactly which finger was responsible for the touch
Unfortunately, the Leap Motion cannot do this. Or at least, if this functionality exists it is not available to developers working with the Leap. You don't get any sort of point cloud, or even raw camera data, all you get is a series of vectors where the Leap has detected linear highlights (and using stereo cameras, deduced to be cylindrical objects) and the positions where it has detected them. You know where fingers are, but not which fingers are which.
It's $1500 for a SoC phone of fairly basic specifications (mainly due to desired low power consumption), and an off-the-shelf display module. As long as they managed to buy the module in bulk from the OEM rather than buying a packaged end-user product from a reseller, then the majority of cost for development would be in creating the interface, not in developing the hardware. Google's voice search and Now already existed from their Android work, so it's specifically the UI they had to adapt for HUD usage. I can imagine they at least broke even selling just a few thousand.
Yes we do. RISC accrued 'useful' instruction sets (e.g. NEON), whilst CISC simplified internally to a more limited set of instructions with an interpreter to turn the full instruction-set (usually x86) into ones the CPU can process, thus turning 'RISC vs CISC' into a decision as to where you want your last arbiter of instruction set simplification to lie: in the compiler (requiring you to recompile all your x86 code), or on the processor die (requiring a small hit to processor cost and complexity).
SEP encompasses a lot of things. Do they mean an Ion thruster (of the various gridded or gridless variants), a Hall-effect thruster, a FEEP thruster, an MPD thruster, a Helicon thruster, a VASIMR engine, an arc-jet or resistojet, etc? There are a lot of electric engines you could hook up to some solar panels (or an RTG, or compact radiatively cooled reactor).
it could be used to make sensors that are smaller and just as good as current sensors
I'm not sure if it could. Pixel sizes for really tiny cameraphone sensors (1.1 microns, or 1100 nm) are getting close to the wavelength of visible red photons (750 nm). If you shrink them anymore, Quantum Stuff starts to happen which you may not really want to happen.
what file format is your image stored in that has eight colour channels
Hoo boy, it's colour theory time! Do you want to store your colours as an intensity and a base colour (located in a 3d colour space e.g. L*,a*,b*), or a linear combination of emissive wavelengths, or an explicit spectrum, etc? Storing the exact colour something emits takes a lot of data. Three primaries correctly chosen are sufficient to record every colour the human eye can perceive, however, which is good enough for every application that involves image reproduction for people to look at (hello computational imagers and hyperspectral imagers and astrophotographers, don't kill me!). Unfortunately, we have no way to print those specific primaries, so we have to throw a load more at the paper to build up an approximate of them.
Slashdot Mirror
A sturdy socket, and a 3D printer. While highly dexterous neurally controlled arms and hands are in development, they're far from an off-the-shelf option. For specific uses (e.g. holding various artists tools) you may well be better off with some sort of magnetic socket on a stump cup, and a rack of special purpose end manipulators for each tool.
Then there's the infamous 'fat electron', which becomes stuck in kinked wiring.
Boot-to-desktop, and some way to categorise/group the tiles on the start screen. I don't really want a return to the 'program-in-a-folder-in-a-folder with piles of uninstall, manuals, help files, tutorials, demos, etc links lying about the tree at random' approach of the start menu, but some sort of organisation beyond just vaguely dragging things about would be nice.
What you are describing is called 'motion interpolation' It is a fundamental part of the last few generations of video CODEC, and the current crop of commonly in-use CODECs (h.264, VP8, ASP) all implement it.
The big problem with 'magic' video enhancers is that mathematically, CODECs are already very, very good at identifying easy to optimise bits of video, so anything your algorithm does is either totally redundant, or just makes things harder to compress (and thus lower quality at the same bitrate, or the same quality requiring a higher bitrate). Identifying what looks good to the human eye, however, is something much harder to do algorithmically. x.264's psy-optimisation was worked out more through iterative trial-and-error than any sort of mathematical system (hence why encoding to optimal PSNR or SSIM is pretty stupid if a human is going to be watching the end-video).
I'd have gone for the more relevant MASK.
I've seen a whole lot of video enhancement 'algorithms', boxes, programs, etc. Not one of the press-button-get-video variants have actually improved video quality, and almost universally they just make things worse; more often than not, they just shove up contrast and saturation and add an unsharp mask, but some are genuinely innovative in their uglyness (e.g. the dreaded WarpSharp, Q-Tec's BD butchery, etc). The vast majority of 'easy to use' variants, with a few sliders to move about or checkboxes to flip, are equally ineffective.
Do you have any examples of your 'algorithm' that show it to be something other than run-of-the-mill?
Running on something other than H2 outside the lab is a breakthrough You can't rely on your cryogenic fuel to cool your engine, you need to build a chamber that will handle massive shockwaves at hilarious temperatures.
The Intercooler operates on a Helium loop, but the loop is closed: it is the Hydrogen fuel that provides the cooling, and no Helium is lost in operation. Additionally, the Intercooler, the hardest part of the engine, has been tested successfully. The rest is running turbines and a rocket on H2, which has been done numerous times in the past.
The big barrier is that it doesn't scale down well at all: you can't built a small vehicle that you can actually use for launching anything, you have to stump up the cash to build the full thing if you want any sort of return on investment.
And since pretty much everyone owns 'fire & forget' missiles that identify, discriminate, lock on and home into targets under on-board terminal guidance, why would anyone want to ban autonomous lethal robots? They've owned and operated them (in anger!) for decades.
Or just kill the damn javascript and use whatever buttons or context menus you want.
Just use this bookmerklet: javascript:(function()%20{%20function%20R(a){ona%20=%20%22on%22+a;%20if(window.addEventListener)%20window.addEventListener(a,%20function%20(e)%20{%20for(var%20n=e.originalTarget;%20n;%20n=n.parentNode)%20n[ona]=null;%20},%20true);%20window[ona]=null;%20document[ona]=null;%20if(document.body)%20document.body[ona]=null;%20}%20R(%22contextmenu%22);%20R(%22click%22);%20R(%22mousedown%22);%20R(%22mouseup%22);%20})()
I thought this was standard operating procedure for any game these days.
I think the difference is between "movie/TV show ostensibly set in vaguely the same universe, and maybe we'll throw in a character or two with the same name" and using stories that actually happened involving player actions.
I'd really like to see one of the many EVE heists play out. There are remarkably few sci-fi heist stories about (the only ones that comes to mind are an episode or two of Firefly, and "Saturday Night and Sunday Morning – CASH EYE", but that was an Oceans Eleven homage).
You just can't do that with buttons.
For page turning, you can definitely use a Kindle with only one hand. If held from the back, you can easily hit the buttons on either side with either your thumb or fingertips. If held folio-style, you can press the page-turn buttons of whichever side you are holding with the flesh of your palm.
It's a micro-display module, small field-of-view, and look-through. It's not exactly ground-breaking technology, and essentially equivalent modules have been on sale for the past couple of decades for anyone willing to actually buy one (and, until the last decade, can afford research/military pricing). Those tiny DLP chips and miniature LCDs used in projectors? They aren't found just in projectors.
With the exception of the omitted cellular modem and amplifiers, and the different display, the components running Google Glass are the same as you'll find in any number of smartphones. $1500 is what they're selling for now (or rather, sold for while available), as a development kit. If they intend to go full-scale, then volume production will further reduce part and manufacturing costs.
Sure, a touch-screen is nicer than a 4-way pad for selecting menu items, but I bought an e-reader to read books, not navigate menus. This is also my beef with the Kindle Touch/Paperwhite/whatever the non low-end models are called now. The basic bog-standard kindle, I can pick it up and hold it while reading without worrying if I'm about to accidentally turn a page, change the font size, exit my book, etc.
I did briefly own Kobo's lower end model for about 2 days before returning it. That one did have buttons, but you also had to go and make a cup of tea between every page turn. Kobo no longer even sell that model, or any others with page-turn buttons.
Only if all fingers are currently present and visible, or all have been present (and externally identified, either using manual calibration or an additional camera and some sort of classifier) at once and the remaining fingers have been continuously visible since (no occlusions), and the hand has not changed orientation. Forming a fist and then extending a single finger would prevent identification.
it would be possible for the device to identify exactly which finger was responsible for the touch
Unfortunately, the Leap Motion cannot do this. Or at least, if this functionality exists it is not available to developers working with the Leap. You don't get any sort of point cloud, or even raw camera data, all you get is a series of vectors where the Leap has detected linear highlights (and using stereo cameras, deduced to be cylindrical objects) and the positions where it has detected them. You know where fingers are, but not which fingers are which.
It's $1500 for a SoC phone of fairly basic specifications (mainly due to desired low power consumption), and an off-the-shelf display module. As long as they managed to buy the module in bulk from the OEM rather than buying a packaged end-user product from a reseller, then the majority of cost for development would be in creating the interface, not in developing the hardware. Google's voice search and Now already existed from their Android work, so it's specifically the UI they had to adapt for HUD usage. I can imagine they at least broke even selling just a few thousand.
And we all know how that one ended.
Yes we do. RISC accrued 'useful' instruction sets (e.g. NEON), whilst CISC simplified internally to a more limited set of instructions with an interpreter to turn the full instruction-set (usually x86) into ones the CPU can process, thus turning 'RISC vs CISC' into a decision as to where you want your last arbiter of instruction set simplification to lie: in the compiler (requiring you to recompile all your x86 code), or on the processor die (requiring a small hit to processor cost and complexity).
Whoops, no it's not, got the MAXX and HD mixed up.
If they offered that with stock android or at least an unlocked boot loader I would have considered it.
If you're willing to buy it off-contract (and thus unsubsidised) such a thing exists, in the US at least.
SEP encompasses a lot of things. Do they mean an Ion thruster (of the various gridded or gridless variants), a Hall-effect thruster, a FEEP thruster, an MPD thruster, a Helicon thruster, a VASIMR engine, an arc-jet or resistojet, etc? There are a lot of electric engines you could hook up to some solar panels (or an RTG, or compact radiatively cooled reactor).
The Daily Mail. The Daily Mail.
For those outside the UK, the Daily Mail (along with other tabloids, e.g. The Sun) are about as accurate a news source as Fox News.
it could be used to make sensors that are smaller and just as good as current sensors
I'm not sure if it could. Pixel sizes for really tiny cameraphone sensors (1.1 microns, or 1100 nm) are getting close to the wavelength of visible red photons (750 nm). If you shrink them anymore, Quantum Stuff starts to happen which you may not really want to happen.
what file format is your image stored in that has eight colour channels
Hoo boy, it's colour theory time! Do you want to store your colours as an intensity and a base colour (located in a 3d colour space e.g. L*,a*,b*), or a linear combination of emissive wavelengths, or an explicit spectrum, etc? Storing the exact colour something emits takes a lot of data. Three primaries correctly chosen are sufficient to record every colour the human eye can perceive, however, which is good enough for every application that involves image reproduction for people to look at (hello computational imagers and hyperspectral imagers and astrophotographers, don't kill me!). Unfortunately, we have no way to print those specific primaries, so we have to throw a load more at the paper to build up an approximate of them.