How does lossless digital zoom compensate for lens quality?
I just meant it as an example of the fact that current phones' camera sensors do offer more pixels than is needed for 720p recording, so they use it for nice extra things such as digital zoom. So why couldn't the sensors of the near future use them for 1080p recording instead?
As for noise reduction, wouldn't a lower resolution sensor of the same physical size be better than an algorithm?
A lower resolution sensor, with the same S/N ratio, would capture less detail. Just dismissing higher resolution sensors as a marketing gimmick ignores the technical advancements in image sensors.
I suppose that higher resolution sensors are needed for still photography, where exposition times can be longer, the camera can be supposed to be still, and the captured image can be downloaded with no hurry from the sensor, so the noise is lower.
Movie filming just reuses the same sensor for a different purpose, where indeed a lower resolution sensor would be more adequate and cheaper, but then it would make the phone shoot worse photos.
</speculation>
You mean a Apple fanboy? Funny, because I just meant to say that Apple's products don't do much, but what they do, they do it well. Which I think is a pretty balanced point of view. I think that the original submission is much more fanboyish.
Nobody but the camera module would see that stream *uncompressed*. Just handling it would probably kill a Core i7, let alone h264-compressing it on the fly.
Why? Current phones' sensors have a much higher resolution than 720p, so they can use the extra detail to achieve lossless digital zoom. For example, the Nokia N8 can zoom "up to 3x" without interpolating pixels with this technique.
What's wrong with using this pixel abundance to shoot 1080p instead? There would still be enough pixels to allow for noise reduction.
Apple, which is generally believed to have the most capable processor in the market today, may be under pressure to roll out a dual-core iPhone next year as well."
Apple has never been about tech specs lists, they're about the quality of their implementations.
They're using a 800 MHz processor in their latest and greatest phone, and they previous model ran fine with 256 MB RAM. I've never seen anybody lamenting the iPhone's performance (well, at least as long as it runs the same firmware version it shipped with).
They will not be "under pressure" to use a dual core CPU next year, it will just be a natural choice by then.
It's great that you can now inspect multimedia-rich web pages and see that all the elements that compose them (including scripts, fonts, sounds) are now first-class citizens, not distinguished from hyperlinks and images, instead of alien entities sealed in a square box in the middle of the page. You can now learn how they work by looking at the code, and even rip the resources you like, as you have always been able to do with text and images. I think HTML5 is a long overdue update to HTML that, in the long run, has a clear potential to finally put an end to the reign of fear of browser plugins, with their security vulnerabilities, performance issues, integration issues, portability issues, compatibility issues, maintenance issues.
About inconsistencies: it would also be interesting to look at how flash content looks like when run outside the canonical windows/unix/mac desktop plugin developed by Adobe. For instance, in Android devices, Nokia devices, on the PS3, or any non-x86 architecture which is served by a different plugin than the Adobe one. There, I'm used to see plenty of inconsistency, transparency issues, animations which just get stuck, sluggish performance, "please update your flash player" messages (of course updating the flash player on a cell phone is usually out of question).
I agree with you that Flash is *the* best way, currently, to run multimedia content that the largest number of desktop users will be able to access. But the availability of high-quality open source html5 engines and the rise in importance of non-x86 portable devices will probably change that in the near future. I think even Adobe is keeping the back-end of their tools open to alternative solutions to Flash, just in case.
Firefox 4 gets 97/100 on the Acid3 test and 574 out of 574 in the CSS3.info selectors test.
Unlike webkit-based browsers, it supports MathML (and has for ages). It also directly targeted WebGL support, whereas other vendors tried to sneak in proprietary standards before giving up.
Say that it is slow, but not that firefox doesn't support open standards.
As far as I know, removal of the OtherOS did nothing to increase the security of the console, even though that was the stated reason.
Except that it *did* close the geohot hack, which required Linux, because it exploited a bug in the hypervisor. In fact, it was geohot himself who, from his blog, told people not to update to the new firmware until his hack was finalised. Which never happened.
That's the reason they removed the option from newer revisions of the console.
But the reason they removed the option from the older consoles which originally shipped with it, was solely geohot's clumsy attempt at pirating the firmware.
I agree with you that it was a niche feature that won't be missed by many people, while a lower price for the console will surely be appreciated more widely.
Whatever mistake MS can have done with their software, is not comparable, from a moral point of view, to deliberately installing a hidden software, with harmful side effects, to take an action against the user's interest, not only without asking the user's permission, but even taking special precautions to ensure that the user never noticed the unwanted installation.
It's so evil that I would even believe it's against one or more laws.
My Nintendo DSi does have an upgradable firmware which is updated once in a while by Nintendo for the sole purpose of disrupting "homebrew" development.
They didn't do anything for Linux support. Cell is PPC based, there are dozens of distos that will run on a PPC arch. They paid YDL to get their distro on the PS3 before the console was even launched. Why? Because they wanted tech kudos to sell a very expensive toy that had very few games for a good 18 months.
They had to develop a hypervisor, and device drivers for every piece of hardware contained in each specific revision of the PS3. They're all costs, and slow down the development of new hardware revisions, which can be a major problem in a highly competitive market.
OtherOS isn't the only thing they've removed since launch. Back compatibility was downgraded to bad software then dropped altogether, card slots were removed SACD was removed, DTS was removed from local M2TS files for over a year. USB ports were reduced. You get the picture here?
I get a console that I can actually afford (unlike the original 600 € PS3). Later, I can buy a 7-port USB hub and a 35-in-1 USB card reader, for a couple of dollars, if and when I need them. SACD? How many SCD discs have been printed ever? PS2 compatibility is the only nice thing one could miss, but then again whoever has PS2 discs in house, will probably have a PS2 as well. Luckily, PS1 compatibility is still there.
I think it's not a good idea to run software which was not designed to run on the version of the OS you're using. Besides using ddraw.dll, those games might also display funny behaviour which was not uncommon in those pre-NT, pre-UAC days, such as installing VxD device drivers, scribbling the registry and tossing DLLs all over the filesystem. A VM could spare you those worries.
See for example DOSBox: it lets you run old games with near-perfect results, and running them in DOSBox is much, much, much easier than getting them to work on a real DOS machine was, back in the days.
But removing IDirectDraw would only break some games from the 90s, while removing CreateWindow (Ex) would kill every single Windows application ever coded.
The contract for the PSN is accepted separately, after you bought and powered on the console, when you create a PSN account, after having read a pretty large license agreement.
Another agreement is displayed before installing any system software upgrade and you have the option to accept it or reject it.
Then again, you're running Windows. Maybe it's that good old "write once for each platform" thing, because it sure doesn't work on my linux box.
No, I'm running Linux. GCJ must have been rewritten and redesigned from scratch between revision 4.4 and 4.5 and changed from a GIJ wrapper to a true compiler.
Again, you only further prove my point - access via java objects sucks. You can get "close" to c performance by using primitives, but then you've eliminated java's overhead for accessing object methods and properties. You can't do that with most java code because most java classes don't have a corresponding "primitive" representation.
Actually, accessing, maintaining and extending classes in Java will be faster and easier than any structure you might call an "object" in C.
So no, higher-level code would run slower in java, because you are stuck at the higher level, when I avoid it.
That's your preference. In Java you can easily invoke C code if you feel you need pointer math.
I don't have to wrap everything into classes.
You wrap everything into functions, because that's how C is designed. Every language invites you to use its native constructs.
Sure, I use classes when necessary, but not necessarily classes. Not when a struct will do.
What's a struct if not a class without methods?
Not when a nice chunk of uninitialized ram will do. Not when some pointer math will solve the problem quickly in one line.
What can you do with pointer math, that can't be done with indexes and arrays? Omitting pointers from the language allows for some optimizations.
The state of the law is currently that you can't copyright an api so anyone is free to reimplement the methods in any class library as long as the reimplementation don't include any code from the original implementation.
That's music to my ears.
This is most likely the reason that Sun is suing for patents, and not copyright. Google have not made any copy of code owed by sun.
Are you sure? I hear that Sun is suing for copyright, too.
(A source).
First of all, you CAN statically link gcj programs (with a recent GCJ, 4.2 or later). Just try:
gcj -static-libgcj -o Foo --main=Foo Foo.java
But you will not WANT to do that, as you will lose some features, and obtain a HUGE executable.
On a side note, are you saying that static linking is the only form of compilation? Isn't "linking" a fully separate process from "compilation"?
If you do, then you're implying that 99% of existing code, being dynamically linked, is not compiled. I think my desktop system has less than twenty statically-linked binaries.
Also, static link has some limitations in modern systems. For instance, some pieces of glibc require, even when statically linked, the presence of the dynamic version (of the same release) of the library at runtime.
No, as the answer I posted on your benchmark shows, Java is almost as fast as C in low-level code. Benchmarking high level code would reveal that Java is *faster* in that field.
You really must have done something wrong to your GCJ. My gcj-compiled java example runs pretty much at the same speed as the C one.
The fact that gcj's standard library is not at par with the Sun one says nothing about the "compilability" of Java code. Perhaps it does show that Java code is easier to write, because IBM and ASF's Java runtime implementations are faring much better.
It's not so and I posted a disassembly of the generated code to show you. Perhaps gcj behaves that way if you feed it a.class file instead of a.java source file?
I do acknowledge that GCJ is not the most advanced Java implementation out there, but nobody has ever said that.
Don't think "full java" has remained constant though. Java6 wouldn't get out of bed for 16Mb RAM.
But today's cheapest smartphone has 128 MB RAM, which I remember were enough to run Windows XP.
And remember it was the performance on pre-Ghz machines which gave Java its reputation for being dog slow.
An undeserved reputation. I can run Python applications on my 300 MHz smartphone, and Java is orders of magnitude faster than Python. I've never heard anybody lamenting Python's speed.
Java does require more RAM tough.
Slashdot Mirror
How does lossless digital zoom compensate for lens quality?
I just meant it as an example of the fact that current phones' camera sensors do offer more pixels than is needed for 720p recording, so they use it for nice extra things such as digital zoom. So why couldn't the sensors of the near future use them for 1080p recording instead?
As for noise reduction, wouldn't a lower resolution sensor of the same physical size be better than an algorithm?
A lower resolution sensor, with the same S/N ratio, would capture less detail. Just dismissing higher resolution sensors as a marketing gimmick ignores the technical advancements in image sensors.
I suppose that higher resolution sensors are needed for still photography, where exposition times can be longer, the camera can be supposed to be still, and the captured image can be downloaded with no hurry from the sensor, so the noise is lower.
Movie filming just reuses the same sensor for a different purpose, where indeed a lower resolution sensor would be more adequate and cheaper, but then it would make the phone shoot worse photos. </speculation>
You mean a Apple fanboy? Funny, because I just meant to say that Apple's products don't do much, but what they do, they do it well. Which I think is a pretty balanced point of view. I think that the original submission is much more fanboyish.
Nobody but the camera module would see that stream *uncompressed*. Just handling it would probably kill a Core i7, let alone h264-compressing it on the fly.
What's wrong with using this pixel abundance to shoot 1080p instead? There would still be enough pixels to allow for noise reduction.
Apple has never been about tech specs lists, they're about the quality of their implementations.
They're using a 800 MHz processor in their latest and greatest phone, and they previous model ran fine with 256 MB RAM. I've never seen anybody lamenting the iPhone's performance (well, at least as long as it runs the same firmware version it shipped with).
They will not be "under pressure" to use a dual core CPU next year, it will just be a natural choice by then.
You can play the content over HDMI. All new high-end phones have a HDMI output.
About inconsistencies: it would also be interesting to look at how flash content looks like when run outside the canonical windows/unix/mac desktop plugin developed by Adobe. For instance, in Android devices, Nokia devices, on the PS3, or any non-x86 architecture which is served by a different plugin than the Adobe one. There, I'm used to see plenty of inconsistency, transparency issues, animations which just get stuck, sluggish performance, "please update your flash player" messages (of course updating the flash player on a cell phone is usually out of question).
I agree with you that Flash is *the* best way, currently, to run multimedia content that the largest number of desktop users will be able to access. But the availability of high-quality open source html5 engines and the rise in importance of non-x86 portable devices will probably change that in the near future. I think even Adobe is keeping the back-end of their tools open to alternative solutions to Flash, just in case.
Firefox 4 gets 97/100 on the Acid3 test and 574 out of 574 in the CSS3.info selectors test.
Unlike webkit-based browsers, it supports MathML (and has for ages). It also directly targeted WebGL support, whereas other vendors tried to sneak in proprietary standards before giving up.
Say that it is slow, but not that firefox doesn't support open standards.
As far as I know, removal of the OtherOS did nothing to increase the security of the console, even though that was the stated reason.
Except that it *did* close the geohot hack, which required Linux, because it exploited a bug in the hypervisor. In fact, it was geohot himself who, from his blog, told people not to update to the new firmware until his hack was finalised. Which never happened.
But the reason they removed the option from the older consoles which originally shipped with it, was solely geohot's clumsy attempt at pirating the firmware.
I agree with you that it was a niche feature that won't be missed by many people, while a lower price for the console will surely be appreciated more widely.
It's so evil that I would even believe it's against one or more laws.
Because silently installing a rootkit for DRM purposes is, in my memory, the most evil act of disrespect of the user ever attempted by a company.
My Nintendo DSi does have an upgradable firmware which is updated once in a while by Nintendo for the sole purpose of disrupting "homebrew" development.
Sony removed the Other OS option BECAUSE it had already been used to hack the PS3.
They didn't do anything for Linux support. Cell is PPC based, there are dozens of distos that will run on a PPC arch. They paid YDL to get their distro on the PS3 before the console was even launched. Why? Because they wanted tech kudos to sell a very expensive toy that had very few games for a good 18 months.
They had to develop a hypervisor, and device drivers for every piece of hardware contained in each specific revision of the PS3. They're all costs, and slow down the development of new hardware revisions, which can be a major problem in a highly competitive market.
OtherOS isn't the only thing they've removed since launch. Back compatibility was downgraded to bad software then dropped altogether, card slots were removed SACD was removed, DTS was removed from local M2TS files for over a year. USB ports were reduced. You get the picture here?
I get a console that I can actually afford (unlike the original 600 € PS3). Later, I can buy a 7-port USB hub and a 35-in-1 USB card reader, for a couple of dollars, if and when I need them. SACD? How many SCD discs have been printed ever? PS2 compatibility is the only nice thing one could miss, but then again whoever has PS2 discs in house, will probably have a PS2 as well. Luckily, PS1 compatibility is still there.
Are you describing the Xbox?
See for example DOSBox: it lets you run old games with near-perfect results, and running them in DOSBox is much, much, much easier than getting them to work on a real DOS machine was, back in the days.
But removing IDirectDraw would only break some games from the 90s, while removing CreateWindow (Ex) would kill every single Windows application ever coded.
Another agreement is displayed before installing any system software upgrade and you have the option to accept it or reject it.
Then again, you're running Windows. Maybe it's that good old "write once for each platform" thing, because it sure doesn't work on my linux box.
No, I'm running Linux. GCJ must have been rewritten and redesigned from scratch between revision 4.4 and 4.5 and changed from a GIJ wrapper to a true compiler.
Again, you only further prove my point - access via java objects sucks. You can get "close" to c performance by using primitives, but then you've eliminated java's overhead for accessing object methods and properties. You can't do that with most java code because most java classes don't have a corresponding "primitive" representation.
Actually, accessing, maintaining and extending classes in Java will be faster and easier than any structure you might call an "object" in C.
So no, higher-level code would run slower in java, because you are stuck at the higher level, when I avoid it.
That's your preference. In Java you can easily invoke C code if you feel you need pointer math.
I don't have to wrap everything into classes.
You wrap everything into functions, because that's how C is designed. Every language invites you to use its native constructs.
Sure, I use classes when necessary, but not necessarily classes. Not when a struct will do.
What's a struct if not a class without methods?
Not when a nice chunk of uninitialized ram will do. Not when some pointer math will solve the problem quickly in one line.
What can you do with pointer math, that can't be done with indexes and arrays? Omitting pointers from the language allows for some optimizations.
http://gcc.gnu.org/wiki/Statically_linking_libgcj
The state of the law is currently that you can't copyright an api so anyone is free to reimplement the methods in any class library as long as the reimplementation don't include any code from the original implementation.
That's music to my ears.
This is most likely the reason that Sun is suing for patents, and not copyright. Google have not made any copy of code owed by sun.
Are you sure? I hear that Sun is suing for copyright, too. (A source).
gcj -static-libgcj -o Foo --main=Foo Foo.java
But you will not WANT to do that, as you will lose some features, and obtain a HUGE executable.
On a side note, are you saying that static linking is the only form of compilation? Isn't "linking" a fully separate process from "compilation"?
If you do, then you're implying that 99% of existing code, being dynamically linked, is not compiled. I think my desktop system has less than twenty statically-linked binaries.
Also, static link has some limitations in modern systems. For instance, some pieces of glibc require, even when statically linked, the presence of the dynamic version (of the same release) of the library at runtime.
I do acknowledge that GCJ is not the most advanced Java implementation out there, but nobody has ever said that.
Don't think "full java" has remained constant though. Java6 wouldn't get out of bed for 16Mb RAM.
But today's cheapest smartphone has 128 MB RAM, which I remember were enough to run Windows XP.
And remember it was the performance on pre-Ghz machines which gave Java its reputation for being dog slow.
An undeserved reputation. I can run Python applications on my 300 MHz smartphone, and Java is orders of magnitude faster than Python. I've never heard anybody lamenting Python's speed. Java does require more RAM tough.