Google destroys the operating system, sort of
ZnU
trickling out. Here's a concept video:
http://www.youtube.com/watch?v=hJ57xzo287U
Chrome OS seems to be a pretty radical departure from the last 25 years
of desktop UI. For starters, it has no desktop. It boots directly to
something a lot like a browser view. It doesn't seem to support
pixel-level positioning for windows, either. It has only full-screen
windows (with tabs) plus pop-up panels that can be docked to screen
edges in sidebars. There also might be some provision (mentioned in
other material here: http://www.chromium.org/chromium-os/user-experience)
for placing multiple windows on-screen side by side if they need to be
viewed simultaneously, but there still wouldn't really be any window
management.
Chrome OS also largely eliminates any sort of local file management. It
only supports SSDs, not hard disks, and it doesn't appear to have much
of a file manager; I suspect local internal storage is basically just
used to store the OS itself and databases for apps making use of HTML5
local storage features. It also supports external storage devices like
USB memory cards, the contents of which seem to appear on the pop-up
panels describe above, so that, for instance, an image from a memory
card can be uploaded somewhere.
As of right now, Google is only positioning Chrome OS as a system for
small low-cost devices (netbooks, as far as I can tell). It seems like
an interesting system for the fairly simple uses to which most netbooks
are bit. It will be even more interesting to see if they can (or will)
try to build a more capable general-purpose computing platform up around
the new paradigm.
The key to doing so would, of course, be allowing third-party apps more
sophisticated access to local resources than JavaScript/HTML5 currently
provide. It will be especially interesting if Google decides to provide
such access by extending web standards, which I suspect is the approach
they'd want to take. Imagine a world where you can point your browser at
a URL and load a web app that provides, say, the functionality of
iMovie, can ingest and work with local footage -- and works on any
platform with a (2012 or later model) browser.
--
"The game of professional investment is intolerably boring and over-exacting to
anyone who is entirely exempt from the gambling instinct; whilst he who has it
must pay to this propensity the appropriate toll." -- John Maynard Keynes
Sandman
ZnU <z...@fake.invalid> wrote:
It sounds good on paper, but I doubt it in practice. I think Google
can't wait for others to stand by their proposals for new standards
because, well, they don't have an OS to support with them (i.e. no
need for support for standards that allow iMovie-like editing in
Firefox, since it's a desktop client, and the desktop already has
tools for that). This means that Google will instead build on their
Gears solution, but make it Chrome OS-specific, further seperating
their solution from any standard.
Gears is today their middleway in waiting for the File API and offline
storage (for example), and I suspect that this restlessness in
standards will only further manifest itself in Chrome OS.
And while I like new takes on UI (such as www.litl.com) I think this
entire file handling issue is bigger than Google expects. So you've
got your spreadsheet in Google Docs and want to mail it? Fine, no
problem, just send it with Gmail. Yeah, ok, but what if I want to send
it through IM? THe video shows a user sending a file via IM from a USB
memory, but how does it handle drag and drop from URLs? I suspect it
might work, in google apps, but what about uploading a spreadsheet to
another non-Google web site? Today, you need to save it to the disk
first, but how will this work in Google Chrome? And that's just
scratching the surface, really.
--
Sandman[.net]
ZnU
Sandman <m...@sandman.net> wrote:
I'm sure Google will run ahead of the standards process -- that's
basically normal practice for innovative web technology companies. But I
suspect they do have an interest in eventually pushing all of these
things as web standards. And it's not entirely unclear to me that if
Google and possibly other developers are designing really cool web apps
that take advantage of this stuff, that Apple and Mozilla wouldn't start
to support some of it.
(Microsoft never will, of course, because it's another middleware
platform designed to undermine the applications barrier to entry that
protects Windows.)
> And while I like new takes on UI (such as www.litl.com) I think this
> entire file handling issue is bigger than Google expects. So you've
> got your spreadsheet in Google Docs and want to mail it? Fine, no
> problem, just send it with Gmail. Yeah, ok, but what if I want to send
> it through IM? THe video shows a user sending a file via IM from a USB
> memory, but how does it handle drag and drop from URLs? I suspect it
> might work, in google apps, but what about uploading a spreadsheet to
> another non-Google web site? Today, you need to save it to the disk
> first, but how will this work in Google Chrome? And that's just
> scratching the surface, really.
The ultimate long-term solution here is to move past working with
discrete files and toward standards that allow the the seamless sharing
of cloud-based data in intelligent format-specific ways.
Sandman
ZnU <z...@fake.invalid> wrote:
> > It sounds good on paper, but I doubt it in practice. I think Google
> > can't wait for others to stand by their proposals for new standards
> > because, well, they don't have an OS to support with them (i.e. no
> > need for support for standards that allow iMovie-like editing in
> > Firefox, since it's a desktop client, and the desktop already has
> > tools for that). This means that Google will instead build on their
> > Gears solution, but make it Chrome OS-specific, further seperating
> > their solution from any standard.
> >
> > Gears is today their middleway in waiting for the File API and offline
> > storage (for example), and I suspect that this restlessness in
> > standards will only further manifest itself in Chrome OS.
>
> I'm sure Google will run ahead of the standards process -- that's
> basically normal practice for innovative web technology companies. But I
> suspect they do have an interest in eventually pushing all of these
> things as web standards. And it's not entirely unclear to me that if
> Google and possibly other developers are designing really cool web apps
> that take advantage of this stuff, that Apple and Mozilla wouldn't start
> to support some of it.
Well, if most of the new "standards" derived from Chrome is
Google-only, it would be on the same level as everything "standard"
that is IE-only.
As a CMS-builder, I would really have loved for the File API part of
HTML5 to be more widespread by now, and I actually think Google Gears
has damaged this progress somewhat.
> > And while I like new takes on UI (such as www.litl.com) I think this
> > entire file handling issue is bigger than Google expects. So you've
> > got your spreadsheet in Google Docs and want to mail it? Fine, no
> > problem, just send it with Gmail. Yeah, ok, but what if I want to send
> > it through IM? THe video shows a user sending a file via IM from a USB
> > memory, but how does it handle drag and drop from URLs? I suspect it
> > might work, in google apps, but what about uploading a spreadsheet to
> > another non-Google web site? Today, you need to save it to the disk
> > first, but how will this work in Google Chrome? And that's just
> > scratching the surface, really.
>
> The ultimate long-term solution here is to move past working with
> discrete files and toward standards that allow the the seamless sharing
> of cloud-based data in intelligent format-specific ways.
But this would only work for basic consumer stuff, really. While basic
consumers surely have tens of gigs worths of music that could be
replaced by cloud-based versions, like Spotify, the same consumer has
even MORE (storage-wise) photos today. My iPhoto-library is 70GB
today, for instance.
If you take company data into account, or even illegal file sharing
(which amounts to the majority of bandwidth being used today), I can't
see a cloud-based solution really...
--
Sandman[.net]
Chris Ahlstrom
> If you take company data into account, or even illegal file sharing
> (which amounts to the majority of bandwidth being used today), ...
How do you know that the majority of bandwidth is due to illegal file
sharing? How does it compare to:
- streaming radio
- streaming video
- you-tube type venues
- download free software ISOs
- the totality of Web access
--
A vivid and creative mind characterizes you.
TomB
On 2009-11-21, the following emerged from the brain of Chris Ahlstrom:
> Sandman pulled this Usenet boner:
>
>> If you take company data into account, or even illegal file sharing
>> (which amounts to the majority of bandwidth being used today), ...
>
> How do you know that the majority of bandwidth is due to illegal file
> sharing? How does it compare to:
>
> - streaming radio
> - streaming video
> - you-tube type venues
> - download free software ISOs
> - the totality of Web access
I wouldn't say it's the majority, but it certainly is an awful lot.
One single HD rip of let's say 10 GB equals:
- Almost 7 days of non-stop streaming radio at 128kbps
- 14 CD images of your favorite GNU/Linux distro
- 1/2 million emails of 20kB
Now that's a lot of traffic ;-)
--
You will gain money by an immoral action.
ZnU
Sandman <m...@sandman.net> wrote:
> In article <znu-B1A2C5.1...@Port80.Individual.NET>,
> ZnU <z...@fake.invalid> wrote:
[snip]
> > The ultimate long-term solution here is to move past working with
> > discrete files and toward standards that allow the the seamless sharing
> > of cloud-based data in intelligent format-specific ways.
>
> But this would only work for basic consumer stuff, really. While basic
> consumers surely have tens of gigs worths of music that could be
> replaced by cloud-based versions, like Spotify, the same consumer has
> even MORE (storage-wise) photos today. My iPhoto-library is 70GB
> today, for instance.
>
> If you take company data into account, or even illegal file sharing
> (which amounts to the majority of bandwidth being used today), I can't
> see a cloud-based solution really...
What I'm thinking of doesn't necessarily mean giving up all local
storage. It's more a matter of replacing files, which are the dominant
metaphor for working with data on the desktop, with globally addressable
structured high-level data elements, which rule in the cloud.
The desktop is moving in this direction already, sort of.
A decade ago, when early adopters took photos with their newfangled
digital cameras, they generally thought of those photos as files and
managed them in a file manager.
Today, they're far more likely to manage them using an app like iPhoto,
which understands a lot more about photos than a generic file manager
does, and hides all the details of the actual file storage from the
user. Even more importantly, when working with those photos from other
applications, Apple provides APIs that allow the user to simply work
with the iPhoto library from other apps.
The key distinction is that instead of the user working with "image
files" -- chunks of data that are largely opaque to the operating system
-- the user works with "photos", which the system understands as a
primitive type. That is, a photo is no longer a type of file, it's just
a type of data that OS knows how to work with in addition to files.
This is sort of how the cloud works. For the most part, discrete files
don't exist in the cloud. Look at something like Flickr. It's very much
built along the same lines as OS X's photo library support -- there's an
application roughly equivalent to iPhoto (the main Flickr web site) for
accessing and manipulating photos, and there's an API that provides
access to other applications that want to access that same data and
functionality.
There is a key difference, however. The Flickr application and the data
it acts as a gateway for are globally addressable. You can pull up the
application with nothing more than a URL and a browser. Most specific
data elements have their own unique addresses. Data can therefore be
passed around "by reference" rather than just "by value", and specific
functionality of the app can be invoked remotely.
This is what makes the cloud a cloud, rather than, to abuse the metaphor
a bit, a bunch of isolated individual water droplets.
It's easy to see how cloud/desktop convergence could play out here.
Bring global addressability to the desktop. Instead of local
applications working with files, they work with high-level structured
data that can be accessed through standardized type-specific APIs. Code
running on your local machine would expose your locally stored photo
library through an API much like the one Flickr uses to expose access to
the photos it stores. This API would be based on open web technologies
(XML-RPC, etc.) and would be the standard mechanism through which both
local and remote applications accessed that data and any functionality
exposed by the process that implemented the API (maybe it can rotate
photos, crop them, perform image recognition, whatever).
Instead of having a world of structured API-accessible data in the
cloud, and discrete applications and files on the desktop, this brings
cloud-style data management onto the desktop, allowing both the
elimination of traditional files and file systems (except possibly as
internal implementation details) and seamless integration between local
and remote data and functionality. Your local machine would be fully
integrated into the cloud, rather than merely being a terminal for
accessing the cloud.
ZnU
JEDIDIAH <je...@nomad.mishnet> wrote:
> On 2009-11-21, RonB <ronb02...@gmail.com> wrote:
> >
> >
> > TomB wrote:
> >
> >> I wouldn't say it's the majority, but it certainly is an awful lot.
> >> One single HD rip of let's say 10 GB equals:
> >>
> >> - Almost 7 days of non-stop streaming radio at 128kbps
> >> - 14 CD images of your favorite GNU/Linux distro
> >> - 1/2 million emails of 20kB
> >>
> >> Now that's a lot of traffic ;-)
> >
> > You completely ignored Hulu, YouTube and news feed videos. I don't watch
> > TV anymore. If I want to see a show I watch it on Hulu. If I want to
> > take a look at NFL highlights, I watch them on NFL.com. And my kids (at
> > the same time) may be watching Cartoon Network, or playing an online
> > game. To assume the bulk of Internet bandwidth is illegal file sharing
> > is just that, an assumption.
>
> ...also, your average movie "rip" is not going to be 10G. It's going to
> be more like 1G. It will be heavily compressed much like the sort of
> stuff they call HD in the iTunes store.
Your typical HD movie on iTunes is more like 3-4 GB, and looks, in my
professional opinion, pretty good. Even on the 92" screen in the HD
screening room at the office.
With decent compression work, 4-5 Mbps H.264 is fine for 720p24 content.
As good as the 25-30 Mb 1080p24 H.264 or VC1 on most Blu-ray discs? Not
quite. But better than pretty much anything else, including over the air
and cable HD, Netflix HD streaming, and, of course SD DVD. (Actually,
the best Netflix streaming might look as good as iTunes HD content, but
Netflix seems to have more consistency issues, I suspect because of the
source material they're provided with.)
Mind you, I'm not going to be buying a lot of iTunes HD content until
the industry figures out that people don't really want to pay as much
for a digital download as for a physical disc.
Sandman
Chris Ahlstrom <ahls...@launchmodem.com> wrote:
> > If you take company data into account, or even illegal file sharing
> > (which amounts to the majority of bandwidth being used today), ...
>
> How do you know that the majority of bandwidth is due to illegal file
> sharing?
Logic.
> How does it compare to:
>
> - streaming radio
More.
> - streaming video
More.
> - you-tube type venues
More.
> - download free software ISOs
More.
> - the totality of Web access
More.
--
Sandman[.net]
Sandman
ZnU <z...@fake.invalid> wrote:
I understand all of this perfectly well, and I don't object to media
management with a specific UI designed for that purpose instead of a
file manager, my concern is about the 4GB of storage space in Chrome
OS, which obviously can't hold this locally, so you're stuck with
saving it all remotely, which I think would be a problem, not only
because of storage space, but also because of privacy.
> There is a key difference, however. The Flickr application and the data
> it acts as a gateway for are globally addressable. You can pull up the
> application with nothing more than a URL and a browser. Most specific
> data elements have their own unique addresses. Data can therefore be
> passed around "by reference" rather than just "by value", and specific
> functionality of the app can be invoked remotely.
>
> This is what makes the cloud a cloud, rather than, to abuse the metaphor
> a bit, a bunch of isolated individual water droplets.
Hehe :)
> It's easy to see how cloud/desktop convergence could play out here.
> Bring global addressability to the desktop. Instead of local
> applications working with files, they work with high-level structured
> data that can be accessed through standardized type-specific APIs. Code
> running on your local machine would expose your locally stored photo
> library through an API much like the one Flickr uses to expose access to
> the photos it stores. This API would be based on open web technologies
> (XML-RPC, etc.) and would be the standard mechanism through which both
> local and remote applications accessed that data and any functionality
> exposed by the process that implemented the API (maybe it can rotate
> photos, crop them, perform image recognition, whatever).
If I understand you correctly here, you're suggesting that a site like
Flickr could have access to my locally stored photos? If that's not
what you mean, I still think that's a pretty neat idea. It wouldn't
apply to Chrome OS, of course, but I sort of like the idea of photos
being stored in a open media library on my Mac, and iPhoto would just
be a front end to that library. I could just as well use FLickr or
Picasa to manage my photos, and those UI's are remote.
> Instead of having a world of structured API-accessible data in the
> cloud, and discrete applications and files on the desktop, this brings
> cloud-style data management onto the desktop, allowing both the
> elimination of traditional files and file systems (except possibly as
> internal implementation details) and seamless integration between local
> and remote data and functionality. Your local machine would be fully
> integrated into the cloud, rather than merely being a terminal for
> accessing the cloud.
As I said, this is a neat idea, but it wouldn't apply to Chrome OS,
which is what I talked about :)
--
Sandman[.net]
ZnU
Sandman <m...@sandman.net> wrote:
> In article <znu-8904BC.1...@Port80.Individual.NET>,
> ZnU <z...@fake.invalid> wrote:
[snip]
> > It's easy to see how cloud/desktop convergence could play out here.
> > Bring global addressability to the desktop. Instead of local
> > applications working with files, they work with high-level structured
> > data that can be accessed through standardized type-specific APIs. Code
> > running on your local machine would expose your locally stored photo
> > library through an API much like the one Flickr uses to expose access to
> > the photos it stores. This API would be based on open web technologies
> > (XML-RPC, etc.) and would be the standard mechanism through which both
> > local and remote applications accessed that data and any functionality
> > exposed by the process that implemented the API (maybe it can rotate
> > photos, crop them, perform image recognition, whatever).
>
> If I understand you correctly here, you're suggesting that a site like
> Flickr could have access to my locally stored photos? If that's not
> what you mean, I still think that's a pretty neat idea. It wouldn't
> apply to Chrome OS, of course, but I sort of like the idea of photos
> being stored in a open media library on my Mac, and iPhoto would just
> be a front end to that library. I could just as well use FLickr or
> Picasa to manage my photos, and those UI's are remote.
Right. The idea is that anything -- any local or remote app -- could
have access to the photos or other data on your Mac, using APIs much
like the ones that other web sites and desktop clients use to access
content on Flickr and other web sites that expose such APIs.
> > Instead of having a world of structured API-accessible data in the
> > cloud, and discrete applications and files on the desktop, this brings
> > cloud-style data management onto the desktop, allowing both the
> > elimination of traditional files and file systems (except possibly as
> > internal implementation details) and seamless integration between local
> > and remote data and functionality. Your local machine would be fully
> > integrated into the cloud, rather than merely being a terminal for
> > accessing the cloud.
>
> As I said, this is a neat idea, but it wouldn't apply to Chrome OS,
> which is what I talked about :)
It wouldn't apply to Chrome OS in its current incarnation, but it is an
important part of a roadmap for how Chrome OS could be turned into
something with at least as much functionality as traditional desktop
systems, while still very much being a system born on the web and
designed for the cloud.
Chris Ahlstrom
> In article <he98t7$562$2...@news.eternal-september.org>,
Zzzzzzzzzzzzzzzzzzzz.
That is what your "logic" does to me, Mr. Sandman.
--
Mr. Sandman! Lend me a dream!
Make her complexion like peaches and cream!
Snit
11/22/09 12:09 AM:
> In article <he98t7$562$2...@news.eternal-september.org>,
> Chris Ahlstrom <ahls...@launchmodem.com> wrote:
>
>>> If you take company data into account, or even illegal file sharing
>>> (which amounts to the majority of bandwidth being used today), ...
>>
>> How do you know that the majority of bandwidth is due to illegal file
>> sharing?
>
> Logic.
But not a shred of support. OK.
--
[INSERT .SIG HERE]
Snit
11/22/09 12:18 AM:
>> Today, they're far more likely to manage them using an app like iPhoto,
>> which understands a lot more about photos than a generic file manager
>> does, and hides all the details of the actual file storage from the
>> user. Even more importantly, when working with those photos from other
>> applications, Apple provides APIs that allow the user to simply work
>> with the iPhoto library from other apps.
>>
>> The key distinction is that instead of the user working with "image
>> files" -- chunks of data that are largely opaque to the operating system
>> -- the user works with "photos", which the system understands as a
>> primitive type. That is, a photo is no longer a type of file, it's just
>> a type of data that OS knows how to work with in addition to files.
>
> I understand all of this perfectly well, and I don't object to media
> management with a specific UI designed for that purpose instead of a
> file manager, my concern is about the 4GB of storage space in Chrome
> OS, which obviously can't hold this locally, so you're stuck with
> saving it all remotely, which I think would be a problem, not only
> because of storage space, but also because of privacy.
Why can't you hold 4 GB of data locally? It works with USB Flash drives...
right?
--
[INSERT .SIG HERE]
Sandman
Chris Ahlstrom <ahls...@launchmodem.com> wrote:
> Mr. Sandman! Lend me a dream!
> Make her complexion like peaches and cream!
Done!
--
Sandman[.net]
chrisv
>Sandman tholed:
>>
>> More.
>
>Zzzzzzzzzzzzzzzzzzzz.
>
>That is what your "logic" does to me, Mr. Sandman.
Yeah, he likes to pull an Edwin, when trapped...
JEDIDIAH
>
>
> In article <slrnhgh69...@nomad.mishnet>,
> JEDIDIAH <je...@nomad.mishnet> wrote:
>
>> On 2009-11-21, RonB <ronb02...@gmail.com> wrote:
>> >
>> >
>> > TomB wrote:
>> >
>> >> I wouldn't say it's the majority, but it certainly is an awful lot.
>> >> One single HD rip of let's say 10 GB equals:
>> >>
>> >> - Almost 7 days of non-stop streaming radio at 128kbps
>> >> - 14 CD images of your favorite GNU/Linux distro
>> >> - 1/2 million emails of 20kB
>> >>
>> >> Now that's a lot of traffic ;-)
>> >
>> > You completely ignored Hulu, YouTube and news feed videos. I don't watch
>> > TV anymore. If I want to see a show I watch it on Hulu. If I want to
>> > take a look at NFL highlights, I watch them on NFL.com. And my kids (at
>> > the same time) may be watching Cartoon Network, or playing an online
>> > game. To assume the bulk of Internet bandwidth is illegal file sharing
>> > is just that, an assumption.
>>
>> ...also, your average movie "rip" is not going to be 10G. It's going to
>> be more like 1G. It will be heavily compressed much like the sort of
>> stuff they call HD in the iTunes store.
>
> Your typical HD movie on iTunes is more like 3-4 GB, and looks, in my
A real HD movie is more like 40G.
[deletia]
So clearly the math has gone wrong somewhere...
--
Oracle... can't live with it... |||
/ | \
can't just replace it with postgres...
chrisv
> ZnU <z...@fake.invalid> wrote:
>>
>> Your typical HD movie on iTunes is more like 3-4 GB, and looks, in my
>
> A real HD movie is more like 40G.
>
>[deletia]
>
> So clearly the math has gone wrong somewhere...
So funny now the world works. The hardware manufacturers tout their
k00l "1080p" displays, while virtually every content provider is
trying to compress/degrade the quality of the content as much as they
can before too many customers complain or defect.
AFAIK, only BluRay comes close to the full HD experience. Possibly
over-the-air...
ZnU
JEDIDIAH <je...@nomad.mishnet> wrote:
A 120 minute 1080p Blu-ray feature is in the 25-30 GB range. However,
Blu-ray's ~30 Mbps data rate is well past the point of diminishing
returns even for 1080p content. H.264 delivers perfectly decent looking
1080p at half of that data rate. Of course there's no reason not to use
the higher data rate with a format that can handle that much data, but
the quality difference isn't as large as you might think.
And 720p is "real HD" too. It's still about three times the number of
pixels of SD, and it still looks a lot better than SD on large HDTVs. In
fact, most people don't actually sit close enough to their screens to be
able to tell the difference between 1080p and 720p (I do, and
practically everyone who sits on my couch for the first time asks why
it's so close to the TV.)
Don't get me wrong; I personally won't pay money for 720p content when
1080p content is available. But I'm in the business, and I watch things
in viewing environments that are set up correctly. 80-90% of the viewing
public isn't going to be able to tell the difference on their setups.
ZnU
chrisv <chr...@nospam.invalid> wrote:
Pretty much. There are still some visible compression artifacts in
noisy/grainy images, and while a few players now support "deep color"
(i.e. 10 bit/channel), most players and all current discs, as far as I'm
aware, are still 8 bits/channel. And it's still 4:2:0 color (though the
human visual system doesn't notice that with most images.)
But Blu-ray does compromise the integrity of professional HD formats
*much* less than SD DVD does that of professional SD formats. And it's
more than good enough for the mass market.
I'm still sort of amazed a format as good as Blu-ray actually made it to
market.
> Possibly over-the-air...
OTA HD isn't that great. Better than what a lot of cable companies are
feeding people, but broadcast HD has no 1080p support, a maximum bit
rate ~30% lower than Blu-ray's typical average, and uses MPEG-2, which
is about half as efficient as the H.264 and VC1 codecs used by Blu-ray
(and most online streaming).
chrisv
>A 120 minute 1080p Blu-ray feature is in the 25-30 GB range. However,
>Blu-ray's ~30 Mbps data rate is well past the point of diminishing
>returns even for 1080p content. H.264 delivers perfectly decent looking
>1080p at half of that data rate. Of course there's no reason not to use
>the higher data rate with a format that can handle that much data, but
>the quality difference isn't as large as you might think.
>
>And 720p is "real HD" too. It's still about three times the number of
>pixels of SD, and it still looks a lot better than SD on large HDTVs.
Of course. It looks fabulous. Even 480p DVD gets one to a pretty
decent size and quality of display, and 720p has 2.25x the pixels.
>In fact, most people don't actually sit close enough to their screens to be
>able to tell the difference between 1080p and 720p (I do, and
>practically everyone who sits on my couch for the first time asks why
>it's so close to the TV.)
Indeed. Most people are buying too-small of an HD display and sitting
too far away from it. They apparently don't understand that HD's
raison d'�tre is so that we can have LARGE displays (or, more
precisely, a display that fills a LARGE angle of view) that aren't
blurry.
A viewing distance of 1.5x to 2x the screen diagonal is what people
should be shooting-for, IMO. (I actually have "sliders" on my couch
feet, so it can be slid closer for HD, futher back for DVD, and
further back yet for optimal audio (playing CD's)).
>Don't get me wrong; I personally won't pay money for 720p content when
>1080p content is available.
Everything else equal, no one would, I suppose. But 720p can be
pretty damn good, as you note. Most of us will also watch lowly DVD's
on our HD displays, and won't suffer too badly...
>But I'm in the business, and I watch things
>in viewing environments that are set up correctly. 80-90% of the viewing
>public isn't going to be able to tell the difference on their setups.
I'm just an engineer and perfectionist. 8)
JEDIDIAH
...which still leaves us with a 5:1 content gap.
> 1080p at half of that data rate. Of course there's no reason not to use
> the higher data rate with a format that can handle that much data, but
> the quality difference isn't as large as you might think.
Sounds like weak excuses from a mindless fanboy.
>
> And 720p is "real HD" too. It's still about three times the number of
...in as much as it's "better than NTSC". That's hardly saying much though.
Is this what Apple is reduced too. Dissembling?
> pixels of SD, and it still looks a lot better than SD on large HDTVs. In
> fact, most people don't actually sit close enough to their screens to be
> able to tell the difference between 1080p and 720p (I do, and
...the same can be easily applied to a mundane DVD without any of the
usual BD or iTunes DRM nonsense. This is especially true for the stuff that
has been mastered with some care at a higher bitrate.
[deletia]
"Why bother taking full advantage of the available technology" and "most
pepole can't tell the difference anyways" is a very slippery slope that doesn't
do DRM purveyors any credit.
--
Unfortunately, the universe will not conform itself to
your fantasies. You have to manage based on what really happens |||
rather than what you would like to happen. This is true of personal / | \
affairs, government and business.
Chris Ahlstrom
> ZnU wrote:
>
>>And 720p is "real HD" too. It's still about three times the number of
>>pixels of SD, and it still looks a lot better than SD on large HDTVs.
>
> Of course. It looks fabulous. Even 480p DVD gets one to a pretty
> decent size and quality of display, and 720p has 2.25x the pixels.
>
>>In fact, most people don't actually sit close enough to their screens to be
>>able to tell the difference between 1080p and 720p (I do, and
>>practically everyone who sits on my couch for the first time asks why
>>it's so close to the TV.)
>
> Indeed. Most people are buying too-small of an HD display and sitting
> too far away from it. They apparently don't understand that HD's
> raison d'?tre is so that we can have LARGE displays (or, more
> precisely, a display that fills a LARGE angle of view) that aren't
> blurry.
>
> A viewing distance of 1.5x to 2x the screen diagonal is what people
> should be shooting-for, IMO. (I actually have "sliders" on my couch
> feet, so it can be slid closer for HD, futher back for DVD, and
> further back yet for optimal audio (playing CD's)).
You redneck! <grin>
My wife and I finally went and bought a 37" 1080p, after having a 24" CRT (a
very nice one, though).
We don't have high-def content (yet), but the picture still looks very much
better. I was suprised that the panorama setting (the center remains the
same, but the sides are stretch to make the picture wide) looks so good --
only with soccer and football field lines can you really detect the
distortion.
It's about the right size, by the way.
--
Cold hands, no gloves.
chrisv
>chrisv pulled this Usenet boner:
>>
>> A viewing distance of 1.5x to 2x the screen diagonal is what people
>> should be shooting-for, IMO. (I actually have "sliders" on my couch
>> feet, so it can be slid closer for HD, futher back for DVD, and
>> further back yet for optimal audio (playing CD's)).
>
>You redneck! <grin>
>
>My wife and I finally went and bought a 37" 1080p, after having a 24" CRT (a
>very nice one, though).
>
>We don't have high-def content (yet), but the picture still looks very much
>better. I was suprised that the panorama setting (the center remains the
>same, but the sides are stretch to make the picture wide) looks so good --
>only with soccer and football field lines can you really detect the
>distortion.
>
>It's about the right size, by the way.
Sure, if you're 5 feet away... 8)
I have a 32" next to my PC, making the viewing distance about 4 feet.
That's about right. And it's "only"720p - plenty good.
ZnU
JEDIDIAH <je...@nomad.mishnet> wrote:
> On 2009-11-23, ZnU <z...@fake.invalid> wrote:
> >
> >
> > In article <slrnhglbv...@nomad.mishnet>,
> > JEDIDIAH <je...@nomad.mishnet> wrote:
[snip]
> > pixels of SD, and it still looks a lot better than SD on large HDTVs. In
> > fact, most people don't actually sit close enough to their screens to be
> > able to tell the difference between 1080p and 720p (I do, and
>
> ...the same can be easily applied to a mundane DVD without any of the
> usual BD or iTunes DRM nonsense. This is especially true for the stuff that
> has been mastered with some care at a higher bitrate.
This really isn't true. First, the percentage gap between SD and 720p is
larger than the percentage gap between 720p and 1080p (about 300% more
pixels vs. 225%). Second, these sorts of relative percentage gaps have
to be judged in the context of actual human vision and real-world
viewing setups.
Consider a couple of extreme cases. Going from VHS to DVD (about 320x240
vs. 720x480) is going to be visible under virtually any realistic
conditions. Going from 1080p (1920x1080) to the 4K digital cinema format
(4096x2304) is going to be essentially invisible unless you're literally
sitting about three feet from a 50" screen.
It turns out that with most non-enthusiast viewing setups, the
difference between 720p and 1080p is also largely invisible.
> [deletia]
>
> "Why bother taking full advantage of the available technology" and
> "most pepole can't tell the difference anyways" is a very slippery
> slope that doesn't do DRM purveyors any credit.
Your obfuscation aside, iTunes HD is at least as good as any format
except Blu-ray, and good enough for typical consumer HD viewing
conditions. "Not quite as good as the best consumer video format ever
created and that most people still don't use" isn't exactly the scathing
indictment you seem to think it is, especially given that iTunes video
content, as compared with Blu-ray content, is usually cheaper, is more
convenient to acquire, works with more types of devices, and has *less*
obnoxious DRM (doesn't mandate the use of HDCP, can legally have several
playable copies and create backups).
Sandman
ZnU <z...@fake.invalid> wrote:
> This really isn't true. First, the percentage gap between SD and 720p is
> larger than the percentage gap between 720p and 1080p (about 300% more
> pixels vs. 225%). Second, these sorts of relative percentage gaps have
> to be judged in the context of actual human vision and real-world
> viewing setups.
>
> Consider a couple of extreme cases. Going from VHS to DVD (about 320x240
> vs. 720x480) is going to be visible under virtually any realistic
> conditions. Going from 1080p (1920x1080) to the 4K digital cinema format
> (4096x2304) is going to be essentially invisible unless you're literally
> sitting about three feet from a 50" screen.
>
> It turns out that with most non-enthusiast viewing setups, the
> difference between 720p and 1080p is also largely invisible.
Which, of course, is dependant on the screen. I saw Coraline
(*fantastic* movie) in 720p on my 46" Sony Bravia TV and it looked
gorgeous. Seeing it on bluray on the same TV made very little
difference, but seeing it on bluray on my 4 meter wide screen on my
1080p projector made a huge difference. 720p and 1080p is noticeably
different there.
In fact, the quality is so good here that I am reluctant to watch DVD
on my cinema screen because it is so noticeably lower quality.
--
Sandman[.net]
Snit
11/26/09 12:41 AM:
Your post reminds me of a quote I recently read:
"There�s a correlation: The bigger TV you have, the dumber you are. Smart
people have TVs, often�but not very big ones." - David Brancaccio
<http://www.sfreporter.com/stories/sfr_talk_the_big_picture/5040/>
--
[INSERT .SIG HERE]
chrisv
> ZnU <z...@fake.invalid> wrote:
>>
>> It turns out that with most non-enthusiast viewing setups, the
>> difference between 720p and 1080p is also largely invisible.
>
>Which, of course, is dependant on the screen. I saw Coraline
>(*fantastic* movie) in 720p on my 46" Sony Bravia TV and it looked
>gorgeous. Seeing it on bluray on the same TV made very little
>difference, but seeing it on bluray on my 4 meter wide screen on my
>1080p projector made a huge difference. 720p and 1080p is noticeably
>different there.
Again, viewing distance is critical. If you are sitting less than 4X
the distance from the 4X-sized screen, you will see more detail.
>In fact, the quality is so good here that I am reluctant to watch DVD
>on my cinema screen because it is so noticeably lower quality.
Sit as far away as you can, for DVD. I slide my couch nearer or
further, depending.
chrisv
>I saw Coraline
>(*fantastic* movie) in 720p on my 46" Sony Bravia TV and it looked
>gorgeous. Seeing it on bluray on the same TV made very little
>difference, but seeing it on bluray on my 4 meter wide screen on my
>1080p projector made a huge difference. 720p and 1080p is noticeably
>different there.
>
>In fact, the quality is so good here that I am reluctant to watch DVD
>on my cinema screen because it is so noticeably lower quality.
Reading the above again, it seems that you may be confusing DVD (which
is 480p) with 720p? Otherwise, what is the source of 720p in your
above comparisons?
Sandman
<chr...@nospam.invalid> wrote:
> > Sandman:
> > I saw Coraline (*fantastic* movie) in 720p on my 46" Sony Bravia
> > TV and it looked gorgeous. Seeing it on bluray on the same TV
> > made very little difference, but seeing it on bluray on my 4
> > meter wide screen on my 1080p projector made a huge difference.
> > 720p and 1080p is noticeably different there.
> >
> > In fact, the quality is so good here that I am reluctant to watch
> > DVD on my cinema screen because it is so noticeably lower
> > quality.
> Chrisv:
> Reading the above again, it seems that you may be confusing DVD
> (which is 480p) with 720p?
Of course not.
> Otherwise, what is the source of 720p in
> your above comparisons?
The Coraline movie I watched was in 720p. But when I got it on Bluray,
it was obviously 1080p, which made a huge difference on my projector,
not so much on my TV.
--
Sandman[.net]
JEDIDIAH
>
>
> In article <4in7h5hf869utoubn...@4ax.com>, chrisv
><chr...@nospam.invalid> wrote:
>
>> > Sandman:
>> > I saw Coraline (*fantastic* movie) in 720p on my 46" Sony Bravia
>> > TV and it looked gorgeous. Seeing it on bluray on the same TV
>> > made very little difference, but seeing it on bluray on my 4
>> > meter wide screen on my 1080p projector made a huge difference.
>> > 720p and 1080p is noticeably different there.
>> >
>> > In fact, the quality is so good here that I am reluctant to watch
>> > DVD on my cinema screen because it is so noticeably lower
>> > quality.
>
>> Chrisv:
>> Reading the above again, it seems that you may be confusing DVD
>> (which is 480p) with 720p?
>
> Of course not.
>
>> Otherwise, what is the source of 720p in
>> your above comparisons?
Television.
Some broadcast HD is sent out as 720p.
Cable providers also tend to downsample to 720p to save on space.
>
> The Coraline movie I watched was in 720p. But when I got it on Bluray,
> it was obviously 1080p, which made a huge difference on my projector,
> not so much on my TV.
>
>
--
It is not true that Microsoft doesn't innovate.
They brought us the email virus.
In my Atari days, such a notion would have |||
been considered a complete absurdity. / | \
Steve de Mena
> On 2009-11-30, Sandman <m...@sandman.net> wrote:
>>
>> In article <4in7h5hf869utoubn...@4ax.com>, chrisv
>> <chr...@nospam.invalid> wrote:
>>
>>>> Sandman:
>>>> I saw Coraline (*fantastic* movie) in 720p on my 46" Sony Bravia
>>>> TV and it looked gorgeous. Seeing it on bluray on the same TV
>>>> made very little difference, but seeing it on bluray on my 4
>>>> meter wide screen on my 1080p projector made a huge difference.
>>>> 720p and 1080p is noticeably different there.
>>>>
>>>> In fact, the quality is so good here that I am reluctant to watch
>>>> DVD on my cinema screen because it is so noticeably lower
>>>> quality.
>>> Chrisv:
>>> Reading the above again, it seems that you may be confusing DVD
>>> (which is 480p) with 720p?
>> Of course not.
>>
>>> Otherwise, what is the source of 720p in
>>> your above comparisons?
>
> Television.
>
> Some broadcast HD is sent out as 720p.
>
> Cable providers also tend to downsample to 720p to save on space.
Except that it doesn't really save space (1080i at 30fps versus 720p
at 60fps).
Steve
chrisv
>><chr...@nospam.invalid> wrote:
>>
>>> Otherwise, what is the source of 720p in
>>> your above comparisons?
>
>Television.
>
> Some broadcast HD is sent out as 720p.
>
> Cable providers also tend to downsample to 720p to save on space.
Maybe, but in this case he seems to have had a "fixed source" of this
particular movie. I'm still not clear on what that source was. Maybe
cable or broadcast...