Re: [opensource-dev] Overview of JPEG 2000 codec

2010-10-01 Thread Yoz Grahame 
On 30 September 2010 22:05, Patrick N.  wrote:

>   How about this, it should greatly accelerate graphic loading in the
> virtual worlds.
>
> http://code.google.com/intl/en/speed/webp/
>

We were discussing that in the office today. It's got promise (for us,
anyway - I'd be surprised if it got much traction on the web any time soon)
but needs the alpha channel work completed at the very least. Progressive
rendering would be nice but it's not vital - we can provide the benefits in
other ways. Having another channel we can use for bump maps would also be
very helpful.

Another format referenced in the discussion is JPEG-XR (originally released
as "HD Photo" by Microsoft, now an ISO standard), which has all of the above
features. It might be worth doing a comparison, bearing in mind that
compression/quality ratio is not the only thing we care about.

-- Yoz
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Overview of JPEG 2000 codec

2010-10-01 Thread Lance Corrimal 
Am Freitag, 1. Oktober 2010, 10:26:46 schrieb Yoz Grahame:

> Another format referenced in the discussion is JPEG-XR (originally released
> as "HD Photo" by Microsoft, now an ISO standard), which has all of the
> above features. It might be worth doing a comparison, bearing in mind that
> compression/quality ratio is not the only thing we care about.


did you ever notice how may people are online in SL only at the beginning of 
the month?

...yes, that's because their connection gets capped after a few days of SL 
usage... because SL kicks up even more traffic than downloading pirated music 
0.o



or in other words, minimizing traffic through higher compression of textures 
could be a nice thing.

bye,
LC
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Overview of JPEG 2000 codec

2010-10-01 Thread Thomas Grimshaw 
  On 01/10/2010 09:54, Lance Corrimal wrote:
> did you ever notice how may people are online in SL only at the 
> beginning of
> the month? ...yes, that's because their connection gets capped after a few 
> days of SL
> usage... because SL kicks up even more traffic than downloading pirated music
> 0.o

Second Life is, at its core, designed to be a bandwidth hungry 
application, and users need to budget for that.

However, an optional discard level cap could be useful to conserve 
bandwidth for people on crappy ISP's (or in australia)

Tom
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Overview of JPEG 2000 codec

2010-10-01 Thread Yoz Grahame 
On 1 October 2010 01:54, Lance Corrimal  wrote:

>
> or in other words, minimizing traffic through higher compression of
> textures
> could be a nice thing.
>

Absolutely, and it's a major factor, it's just not the only one. All the
recent discussion about OpenJPEG vs KDU is because of decode performance,
which is also vital. Plus, the other features I mentioned earlier.

-- Yoz
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Overview of JPEG 2000 codec

2010-10-01 Thread Ann Otoole 


That would indicate we need region/location information panels accessible prior 
to teleport informing people of the expected bandwidth cost of the location. 

That way people on bandwidth limited plans can try to avoid going places that 
are costly.
Want more traffic? Learn how to minimize texture counts.



From: Lance Corrimal 
To: opensource-dev@lists.secondlife.com
Sent: Fri, October 1, 2010 4:54:31 AM
Subject: Re: [opensource-dev] Overview of JPEG 2000 codec

Am Freitag, 1. Oktober 2010, 10:26:46 schrieb Yoz Grahame:

> Another format referenced in the discussion is JPEG-XR (originally released
> as "HD Photo" by Microsoft, now an ISO standard), which has all of the
> above features. It might be worth doing a comparison, bearing in mind that
> compression/quality ratio is not the only thing we care about.


did you ever notice how may people are online in SL only at the beginning of 
the month?

...yes, that's because their connection gets capped after a few days of SL 
usage... because SL kicks up even more traffic than downloading pirated music 
0.o



or in other words, minimizing traffic through higher compression of textures 
could be a nice thing.

bye,
LC
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges



  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Overview of JPEG 2000 codec

2010-10-01 Thread Ambrosia 
I hope the point was brought up  that Webp only does lossy compression
tho, while Jpeg2k Also does lossless.
In light of sculpts requiring lossless compression, I'd not expect the
need for a jpeg2k decoder
to go away anytime soon for at least that kind of texture, alas,
unless lossless textures'd get
stored as PNG images. PNGs result in smaller files than Jpeg2k when
the image is a classic type of texture that'd
use lossless compression, like cliparts with lots of pixels of the
same color, tho Jpeg2k seems to excel at lossless
compression when complex images are involved.

> We were discussing that in the office today. It's got promise (for us,
> anyway - I'd be surprised if it got much traction on the web any time soon)
> but needs the alpha channel work completed at the very least. Progressive
> rendering would be nice but it's not vital - we can provide the benefits in
> other ways. Having another channel we can use for bump maps would also be
> very helpful.
> Another format referenced in the discussion is JPEG-XR (originally released
> as "HD Photo" by Microsoft, now an ISO standard), which has all of the above
> features. It might be worth doing a comparison, bearing in mind that
> compression/quality ratio is not the only thing we care about.
> -- Yoz
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New features in beta version of today... ?

2010-10-01 Thread Elenia 
Laurent Bechir  has wrote : 
>> Hello,

>> Is there new features in this week version of 2.2 beta viewer like there 
>> was last week  or is it just bug fixes this time ? Im' trying to do 
>> videos in french to show the new features when they are some :)

hello

here you are an abstract on the new features of 2.2 beta viewer in french
http://forums.jeuxonline.info/showpost.php?p=21418763&postcount=1




  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New features in beta version of today... ?

2010-10-01 Thread Laurent Bechir 



Elenia a écrit :

hello

here you are an abstract on the new features of 2.2 beta viewer in french
http://forums.jeuxonline.info/showpost.php?p=21418763&postcount=1



Thank you. In fact I've already put these in a first video :

http://youtu.be/OfHz-CuzcOI?hd=1

I just missed the double click teleport feature. It will be in a next 
one. I was wondering if 2.2 will have other features added before its 
release.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New features in beta version of today... ?

2010-10-01 Thread Hitomi Tiponi 
There isn't much there - mainly bug fixes and tidying up.  Even since that 
release there has been very little new functionaliy.

Incidentally it seems that 210676 bears little resemblance to 210670 or 210680 
- 
maybe Esbee got fed up of all the changes that Richard Linden did to the Viewer 
and ditched them (despite them having come in between beta versions).  I know I 
was as they plugged a loophole (using 'panels' under 'layout_stack') that I was 
exploiting to get StarLight to work and meant several hours of re-coding :(.

>Hello,
>
>Is there new features in this week version of 2.2 beta viewer like there 
>was last week  or is it just bug fixes this time ? Im' trying to do 
>videos in french to show the new features when they are some :)
>
>Thank you


  ___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New features in beta version of today... ?

2010-10-01 Thread WolfPup Lowenhar 
Actualy Richard Linden’s work landed in viewer-development two days after the 
beta was branched off. And there are some issues that have come about since the 
drop that are being worked on. So his work should appear in the next beta after 
all the issues have been corrected(bug fixing).

 

From: opensource-dev-boun...@lists.secondlife.com 
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Hitomi Tiponi
Sent: Friday, October 01, 2010 8:46 AM
To: Opensource_dev
Subject: Re: [opensource-dev] New features in beta version of today... ?

 

There isn't much there - mainly bug fixes and tidying up.  Even since that 
release there has been very little new functionaliy.

Incidentally it seems that 210676 bears little resemblance to 210670 or 210680 
- maybe Esbee got fed up of all the changes that Richard Linden did to the 
Viewer and ditched them (despite them having come in between beta versions).  I 
know I was as they plugged a loophole (using 'panels' under 'layout_stack') 
that I was exploiting to get StarLight to work and meant several hours of 
re-coding :(.

>Hello,
>
>Is there new features in this week version of 2.2 beta viewer like there 
>was last week  or is it just bug fixes this time ? Im' trying to do 
>videos in french to show the new features when they are some :)
>
>Thank you

 

No virus found in this incoming message.
Checked by AVG - www.avg.com
Version: 9.0.856 / Virus Database: 271.1.1/3170 - Release Date: 10/01/10 
02:34:00

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Overview of JPEG 2000 codec

2010-10-01 Thread Brian McGroarty 
On Fri, Oct 1, 2010 at 1:54 AM, Lance Corrimal wrote:

> Am Freitag, 1. Oktober 2010, 10:26:46 schrieb Yoz Grahame:
>
> > Another format referenced in the discussion is JPEG-XR (originally
> released
> > as "HD Photo" by Microsoft, now an ISO standard), which has all of the
> > above features. It might be worth doing a comparison, bearing in mind
> that
> > compression/quality ratio is not the only thing we care about.
>
> did you ever notice how may people are online in SL only at the beginning
> of
> the month?
>
> ...yes, that's because their connection gets capped after a few days of SL
> usage... because SL kicks up even more traffic than downloading pirated
> music
>

The concurrency charts don't show evidence of this monthly cycle.


-- 
Brian McGroarty | Linden Lab
Sent from my Newton MP2100 via acoustic coupler
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Reminder - New time for Snowstorm Daily Scrum Meetings

2010-10-01 Thread Sarah (Esbee) Hutchinson 
Good morning all,

My email to the list appears not to have made it to the list yesterday, so
I'm resending now.

Starting today, the Snowstorm Daily Scrum meetings will now be held at
10:30am PT.

I'll be announcing new times for our sprint planning, retrospective and
review meetings by the end of the day as well.

Best,
Esbee
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] New features in beta version of today... ?

2010-10-01 Thread Sarah (Esbee) Hutchinson 
As Wolfpup notes, we didn't get the work from Richard until after the Viewer
2.2 Beta was cut. We won't be introducing new work from viewer-development
until this Beta cycle is complete and the current beta has gone to Release.

- Esbee


On Fri, Oct 1, 2010 at 8:54 AM, WolfPup Lowenhar wrote:

>  Actualy Richard Linden’s work landed in viewer-development two days after
> the beta was branched off. And there are some issues that have come about
> since the drop that are being worked on. So his work should appear in the
> next beta after all the issues have been corrected(bug fixing).
>
>
>
> *From:* opensource-dev-boun...@lists.secondlife.com [mailto:
> opensource-dev-boun...@lists.secondlife.com] *On Behalf Of *Hitomi Tiponi
> *Sent:* Friday, October 01, 2010 8:46 AM
> *To:* Opensource_dev
> *Subject:* Re: [opensource-dev] New features in beta version of today... ?
>
>
>
> There isn't much there - mainly bug fixes and tidying up.  Even since that
> release there has been very little new functionaliy.
>
> Incidentally it seems that 210676 bears little resemblance to 210670 or
> 210680 - maybe Esbee got fed up of all the changes that Richard Linden did
> to the Viewer and ditched them (despite them having come in between beta
> versions).  I know I was as they plugged a loophole (using 'panels' under
> 'layout_stack') that I was exploiting to get StarLight to work and meant
> several hours of re-coding :(.
>
> >Hello,
> >
> >Is there new features in this week version of 2.2 beta viewer like there
> >was last week  or is it just bug fixes this time ? Im' trying to do
> >videos in french to show the new features when they are some :)
> >
> >Thank you
>
>
>
> No virus found in this incoming message.
> Checked by AVG - www.avg.com
> Version: 9.0.856 / Virus Database: 271.1.1/3170 - Release Date: 10/01/10
> 02:34:00
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

2010-10-01 Thread Gigs 
On 09/29/2010 07:06 PM, Kelly Linden wrote:
> * In my mind the biggest issue is that mono scripts will appear 4x worse
> than LSL scripts. This is really the reason I am hesitant to push a
> function like this through before we have the ability for mono scripts
> to better reflect how much memory they may use. We need more development
> time for any solution on that front. Right now because a mono script
> could use 64k, that is the only number we have available to count. Maybe
> it would be nice to have an API to access number of scripts, number of
> LSL vs. Mono scripts, amount of memory used and script time used.
> However we rapidly get away from my desired philosophy of minimal
> interfaces.


Don't overcomplicate things.  Just count mono scripts as 16k as well. 
The average size of them is less than 16k, so it's still a conservative 
number.

We don't need perfection.  The person with 255 scripts in each shoe will 
still show up as using a lot.  Splitting hairs over kilobyte perfect 
accuracy is pointless.

-Jason
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec

2010-10-01 Thread Ponzu 
On Fri, Oct 1, 2010 at 4:58 AM, Thomas Grimshaw  wrote:

>  On 01/10/2010 09:54, Lance Corrimal wrote:
> > did you ever notice how may people are online in SL only at the
> > beginning of
> > the month? ...yes, that's because their connection gets capped after a
> few days of SL
> > usage... because SL kicks up even more traffic than downloading pirated
> music
> > 0.o
>

I have never seen this reflected in the concurrency data.  Maybe it is only
a myth.


>
> Second Life is, at its core, designed to be a bandwidth hungry
> application, and users need to budget for that.
>
> However, an optional discard level cap could be useful to conserve
> bandwidth for people on crappy ISP's (or in australia)
>
> Nobody has crappier internet than I (satellite).  However, before expending
any resources on making SL Faster for people with crappy internet, first you
need to show that there are enough of us to matter, and also that our
internet won't be improving any time soon.  No sense making expensive
changes (cheap ones are fine 8-) for a dwindling group of users.

Which begs the question:  What does the internet connection of current users
look like, and how is that population changing or likely to change in the
future?

regards,
ponzu
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec

2010-10-01 Thread Thomas Grimshaw 
  On 01/10/2010 18:04, Ponzu wrote:
> Nobody has crappier internet than I (satellite).

Well, we're really talking about transfer caps, here, rather than 
available bandwidth.

Available bandwidth can be appeased by the network slider.  But transfer 
caps are the biggest problem, and pretty much everyone in Australia is 
affected, and a lot of people on the less decent ISP's in the UK.

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

2010-10-01 Thread Kent Quirk (Q Linden) 

On Oct 1, 2010, at 12:50 PM, Gigs wrote:

> On 09/29/2010 07:06 PM, Kelly Linden wrote:
>> * In my mind the biggest issue is that mono scripts will appear 4x worse
>> than LSL scripts. This is really the reason I am hesitant to push a
>> function like this through before we have the ability for mono scripts
>> to better reflect how much memory they may use. We need more development
>> time for any solution on that front. Right now because a mono script
>> could use 64k, that is the only number we have available to count. Maybe
>> it would be nice to have an API to access number of scripts, number of
>> LSL vs. Mono scripts, amount of memory used and script time used.
>> However we rapidly get away from my desired philosophy of minimal
>> interfaces.
> 
> 
> Don't overcomplicate things.  Just count mono scripts as 16k as well. 
> The average size of them is less than 16k, so it's still a conservative 
> number.
> 
> We don't need perfection.  The person with 255 scripts in each shoe will 
> still show up as using a lot.  Splitting hairs over kilobyte perfect 
> accuracy is pointless.
> 

I don't actually have an opinion about the right answer, but I will note that 
if this is going to be used for things like banning people, then we can't ever 
change it to be something accurate later. The pattern we see is:

* We build something that has a numeric limit
* Someone builds something that pushes right to the limit
* We change something, and the thing that used to work no longer works
* People scream that we broke content

So if we create a call that returns approximate results now, it *always* has to 
return the same results.

This is one reason we are reluctant to add new measurements; people come to 
depend on them even when they shouldn't.

  Q



___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

2010-10-01 Thread Ponzu 
On Fri, Oct 1, 2010 at 12:50 PM, Gigs  wrote:

>
>
> Don't overcomplicate things.  Just count mono scripts as 16k as well.
> The average size of them is less than 16k, so it's still a conservative
> number.
>
> We don't need perfection.  The person with 255 scripts in each shoe will
> still show up as using a lot.  Splitting hairs over kilobyte perfect
> accuracy is pointless.
>
> Good point.  So, maybe a simple interface would be to provide number of
mono scripts and number of non-mono scripts.  User could make his own memory
per script estimates and multiply to get memory estimate, if needed.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] WebP, a new image format for the Web

2010-10-01 Thread SuezanneC Baskerville 
Google is putting out a new open source image format, said to offer higher
compression rates than JPEG2000.

I just thought someone with the appropriate technical knowledge ought to
take a look at in case it might be useful for use in Second Life.

http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html<%20http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html>

*To improve on the compression that JPEG provides, we used an image
> compressor based on the VP8 codec that Google 
> open-sourcedin
>  May 2010. We applied the techniques from VP8 video intra frame coding to
> push the envelope in still image coding. We also adapted a very lightweight
> container based on 
> RIFF.
> While this container format contributes a minimal overhead of only 20 bytes
> per image, it is extensible to allow authors to save meta-data they would
> like to store.
>
> While the benefits of a VP8 based image format were clear in theory, we
> needed to test them in the real world. In order to gauge the effectiveness
> of our efforts, we randomly picked about 1,000,000 images from the web
> (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without
> perceptibly compromising visual quality. This resulted in an average 39%
> reduction in file size. We expect that developers will achieve in practice
> even better file size reduction with WebP when starting from an uncompressed
> image.
> *


http://code.google.com/speed/webp/
-- 
v i r t u a l   w o r l d   e n t h u s i a s t
-- http://www.google.com/profiles/s u e z a n n e --
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] WebP, a new image format for the Web

2010-10-01 Thread Ron Festa 
VP8 focuses too much on PSNR which for still photo usage comes out blurrier.
Plus Google's ref-spec VP8 is not exactly known for being CPU friendly on
encode or decode. Even then they're comparing to standard JPEG, not JPEG2000
which there has yet to be a comparison test of. Even then its an unproven
format that so far only shows its better at compression then standard JPEG
even when jpgcrunch is used. IMO, its not worth using until the issues are
resolved and even then its still got a long way to go for adoption.

Ron Festa
Virtual Worlds Admin
Division of Continuing Studies at Rutgers University
PGP key: http://bit.ly/b1ZyhY
Phone: 732-474-8583


On Fri, Oct 1, 2010 at 1:15 PM, SuezanneC Baskerville wrote:

> Google is putting out a new open source image format, said to offer higher
> compression rates than JPEG2000.
>
> I just thought someone with the appropriate technical knowledge ought to
> take a look at in case it might be useful for use in Second Life.
>
> http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html
>
> *To improve on the compression that JPEG provides, we used an image
>> compressor based on the VP8 codec that Google 
>> open-sourcedin
>>  May 2010. We applied the techniques from VP8 video intra frame coding to
>> push the envelope in still image coding. We also adapted a very lightweight
>> container based on 
>> RIFF.
>> While this container format contributes a minimal overhead of only 20 bytes
>> per image, it is extensible to allow authors to save meta-data they would
>> like to store.
>>
>> While the benefits of a VP8 based image format were clear in theory, we
>> needed to test them in the real world. In order to gauge the effectiveness
>> of our efforts, we randomly picked about 1,000,000 images from the web
>> (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without
>> perceptibly compromising visual quality. This resulted in an average 39%
>> reduction in file size. We expect that developers will achieve in practice
>> even better file size reduction with WebP when starting from an uncompressed
>> image.
>> *
>
>
> http://code.google.com/speed/webp/
> --
> v i r t u a l   w o r l d   e n t h u s i a s t
> -- http://www.google.com/profiles/s u e z a n n e --
>
> ___
> Policies and (un)subscribe information available here:
> http://wiki.secondlife.com/wiki/OpenSource-Dev
> Please read the policies before posting to keep unmoderated posting
> privileges
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] WebP, a new image format for the Web

2010-10-01 Thread Ron Festa 
Also forgot to add this link as its a good write up and comparison of x264
vs vp8 vs JPEG w/jpgcrunch for still images:
http://x264dev.multimedia.cx/?p=541

Ron Festa
Virtual Worlds Admin
Division of Continuing Studies at Rutgers University
PGP key: http://bit.ly/b1ZyhY
Phone: 732-474-8583


On Fri, Oct 1, 2010 at 1:33 PM, Ron Festa wrote:

> VP8 focuses too much on PSNR which for still photo usage comes out
> blurrier. Plus Google's ref-spec VP8 is not exactly known for being CPU
> friendly on encode or decode. Even then they're comparing to standard JPEG,
> not JPEG2000 which there has yet to be a comparison test of. Even then its
> an unproven format that so far only shows its better at compression then
> standard JPEG even when jpgcrunch is used. IMO, its not worth using until
> the issues are resolved and even then its still got a long way to go for
> adoption.
>
> Ron Festa
> Virtual Worlds Admin
> Division of Continuing Studies at Rutgers University
> PGP key: http://bit.ly/b1ZyhY
> Phone: 732-474-8583
>
>
> On Fri, Oct 1, 2010 at 1:15 PM, SuezanneC Baskerville 
> wrote:
>
>> Google is putting out a new open source image format, said to offer higher
>> compression rates than JPEG2000.
>>
>> I just thought someone with the appropriate technical knowledge ought to
>> take a look at in case it might be useful for use in Second Life.
>>
>> http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html
>>
>> *To improve on the compression that JPEG provides, we used an image
>>> compressor based on the VP8 codec that Google 
>>> open-sourcedin
>>>  May 2010. We applied the techniques from VP8 video intra frame coding to
>>> push the envelope in still image coding. We also adapted a very lightweight
>>> container based on 
>>> RIFF.
>>> While this container format contributes a minimal overhead of only 20 bytes
>>> per image, it is extensible to allow authors to save meta-data they would
>>> like to store.
>>>
>>> While the benefits of a VP8 based image format were clear in theory, we
>>> needed to test them in the real world. In order to gauge the effectiveness
>>> of our efforts, we randomly picked about 1,000,000 images from the web
>>> (mostly JPEGs and some PNGs and GIFs) and re-encoded them to WebP without
>>> perceptibly compromising visual quality. This resulted in an average 39%
>>> reduction in file size. We expect that developers will achieve in practice
>>> even better file size reduction with WebP when starting from an uncompressed
>>> image.
>>> *
>>
>>
>> http://code.google.com/speed/webp/
>> --
>> v i r t u a l   w o r l d   e n t h u s i a s t
>> -- http://www.google.com/profiles/s u e z a n n e --
>>
>> ___
>> Policies and (un)subscribe information available here:
>> http://wiki.secondlife.com/wiki/OpenSource-Dev
>> Please read the policies before posting to keep unmoderated posting
>> privileges
>>
>
>
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] WebP, a new image format for the Web

2010-10-01 Thread Tateru Nino 
 Hmm. Only supports a single image data chunk and no alpha channels in 
this release. True, you could break compatibility and extend it, but I'm 
not sure that's really the way to go. Not close to a drop-in replacement 
yet, even after banging it on some rocks.


On 2/10/2010 3:15 AM, SuezanneC Baskerville wrote:
Google is putting out a new open source image format, said to offer 
higher compression rates than JPEG2000.


I just thought someone with the appropriate technical knowledge ought 
to take a look at in case it might be useful for use in Second Life.


http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html 
<%20http://blog.chromium.org/2010/09/webp-new-image-format-for-web.html>


/To improve on the compression that JPEG provides, we used an
image compressor based on the VP8 codec that Google open-sourced


in May 2010. We applied the techniques from VP8 video intra frame
coding to push the envelope in still image coding. We also adapted
a very lightweight container based on RIFF
.
While this container format contributes a minimal overhead of only
20 bytes per image, it is extensible to allow authors to save
meta-data they would like to store.

While the benefits of a VP8 based image format were clear in
theory, we needed to test them in the real world. In order to
gauge the effectiveness of our efforts, we randomly picked about
1,000,000 images from the web (mostly JPEGs and some PNGs and
GIFs) and re-encoded them to WebP without perceptibly compromising
visual quality. This resulted in an average 39% reduction in file
size. We expect that developers will achieve in practice even
better file size reduction with WebP when starting from an
uncompressed image.
/


http://code.google.com/speed/webp/
--
v i r t u a l   w o r l d   e n t h u s i a s t
-- http://www.google.com/profiles/s u e z a n n e --


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges


--
Tateru Nino
http://dwellonit.taterunino.net/

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec

2010-10-01 Thread Ponzu 
On Fri, Oct 1, 2010 at 1:06 PM, Thomas Grimshaw  wrote:

>  On 01/10/2010 18:04, Ponzu wrote:
>
>> Nobody has crappier internet than I (satellite).
>>
>
> Well, we're really talking about transfer caps, here, rather than available
> bandwidth.
>
> Available bandwidth can be appeased by the network slider.  But transfer
> caps are the biggest problem, and pretty much everyone in Australia is
> affected, and a lot of people on the less decent ISP's in the UK.
>
>
and me.  17GB per 30 day period, in a sliding window.

Point is still that caps will be increased as time goes on (or decreased, as
international economic system collapses, but taht is a differnt sim).
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

2010-10-01 Thread Ponzu 
On Fri, Oct 1, 2010 at 1:07 PM, Kent Quirk (Q Linden) wrote:

>
>
>
> I don't actually have an opinion about the right answer, but I will note
> that if this is going to be used for things like banning people, then we
> can't ever change it to be something accurate later. The pattern we see is:
>
> * We build something that has a numeric limit
> * Someone builds something that pushes right to the limit
> * We change something, and the thing that used to work no longer works
> * People scream that we broke content
>
> So if we create a call that returns approximate results now, it *always*
> has to return the same results.
>
> At some point (sooner better than later) SL has to start obsoleting old
ways of doing things.  To my way of thinking, it is better to obsolete a
little bit overy so often rather than keep backwad compatibility until you
have to break a lot at once.
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

[opensource-dev] New Snowstorm Team Scrum Meeting Times

2010-10-01 Thread Sarah (Esbee) Hutchinson 
Hi all,

I've just finished adjusting our team calendar to reflect our new meeting
times - these should work well for both east and west coasters moving
forward. :)

*Snowstorm Team Daily Scrum - *Daily from 10:30-10:45am PT

*Sprint Planning Meeting - *Every two weeks on Tuesday from 10-1pm PT
*Next one is Tuesday, Oct 5*

*Sprint Review Meeting - *Every two weeks on Friday from 1-2pm PT
*Next one is Friday, Oct 15*

*Sprint Retrospective Meeting - *Every two weeks on Monday from
11:30-12:30pm PT
*Next one if Monday, Oct 18*
*
*
*Snowstorm Team Members - If you have any overlaps, please make every effort
to rearrange other meetings so we won't have to move these meetings around
weekly. Thank you!!*
*
*
Cheers!
Esbee
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec

2010-10-01 Thread Brian McGroarty 
On Fri, Oct 1, 2010 at 11:41 AM, Ponzu  wrote:

> On Fri, Oct 1, 2010 at 1:06 PM, Thomas Grimshaw wrote:
>
>>  On 01/10/2010 18:04, Ponzu wrote:
>>
>>> Nobody has crappier internet than I (satellite).
>>>
>>
>> Well, we're really talking about transfer caps, here, rather than
>> available bandwidth.
>>
>> Available bandwidth can be appeased by the network slider.  But transfer
>> caps are the biggest problem, and pretty much everyone in Australia is
>> affected, and a lot of people on the less decent ISP's in the UK.
>>
>>
> and me.  17GB per 30 day period, in a sliding window.
>
> Point is still that caps will be increased as time goes on (or decreased,
> as international economic system collapses, but taht is a differnt sim).
>

Devs concerned about crazy-limited connections shouldn't worry about the
small changes that may someday come with a different image CODEC. They can
cut texture transfers in half -today- at the expense of texture blurriness.

A test should be straightforward, if anyone feels strongly enough to take a
whack at it. Add a "texture fidelity" slider that scales the measure the
viewer uses to decide what discard level it wants. See where you still find
it tolerable.

-- 
Brian McGroarty | Linden Lab
Sent from my Newton MP2100 via acoustic coupler
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec

2010-10-01 Thread Tateru Nino 



On 2/10/2010 5:22 AM, Brian McGroarty wrote:
On Fri, Oct 1, 2010 at 11:41 AM, Ponzu > wrote:


On Fri, Oct 1, 2010 at 1:06 PM, Thomas Grimshaw
mailto:t...@streamsense.net>> wrote:

 On 01/10/2010 18:04, Ponzu wrote:

Nobody has crappier internet than I (satellite).


Well, we're really talking about transfer caps, here, rather
than available bandwidth.

Available bandwidth can be appeased by the network slider.
 But transfer caps are the biggest problem, and pretty much
everyone in Australia is affected, and a lot of people on the
less decent ISP's in the UK.


and me.  17GB per 30 day period, in a sliding window.
Point is still that caps will be increased as time goes on (or
decreased, as international economic system collapses, but taht is
a differnt sim).


Devs concerned about crazy-limited connections shouldn't worry about 
the small changes that may someday come with a different image CODEC. 
They can cut texture transfers in half -today- at the expense of 
texture blurriness.


A test should be straightforward, if anyone feels strongly enough to 
take a whack at it. Add a "texture fidelity" slider that scales the 
measure the viewer uses to decide what discard level it wants. See 
where you still find it tolerable.
I read that three times, with different reactions. After a little 
thought, though, yes. I'd _totally_ use that if it were an option. Right 
on the main UI next to a draw-distance slider.


--
Tateru Nino
http://dwellonit.taterunino.net/

___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] Faster for people with crappy internet? (was Re: Overview of JPEG 2000 codec

2010-10-01 Thread Glen Canaday 
On Sat, 2010-10-02 at 05:45 +1000, Tateru Nino wrote:
> 
> 
> On 2/10/2010 5:22 AM, Brian McGroarty wrote: 
> > On Fri, Oct 1, 2010 at 11:41 AM, Ponzu  wrote:
> > On Fri, Oct 1, 2010 at 1:06 PM, Thomas Grimshaw
> >  wrote:
> >  On 01/10/2010 18:04, Ponzu wrote:
> > Nobody has crappier internet than I
> > (satellite).
> > 
> > 
> > Well, we're really talking about transfer caps,
> > here, rather than available bandwidth.
> > 
> > Available bandwidth can be appeased by the network
> > slider.  But transfer caps are the biggest problem,
> > and pretty much everyone in Australia is affected,
> > and a lot of people on the less decent ISP's in the
> > UK.
> > 
> > 
> > and me.  17GB per 30 day period, in a sliding window.
> >  
> > Point is still that caps will be increased as time goes on
> > (or decreased, as international economic system collapses,
> > but taht is a differnt sim).
> > 
> > 
> > Devs concerned about crazy-limited connections shouldn't worry about
> > the small changes that may someday come with a different image
> > CODEC. They can cut texture transfers in half -today- at the expense
> > of texture blurriness. 
> > 
> > 
> > A test should be straightforward, if anyone feels strongly enough to
> > take a whack at it. Add a "texture fidelity" slider that scales the
> > measure the viewer uses to decide what discard level it wants. See
> > where you still find it tolerable.
> > 
> I read that three times, with different reactions. After a little
> thought, though, yes. I'd _totally_ use that if it were an option.
> Right on the main UI next to a draw-distance slider.
> -- 
> Tateru Nino
> http://dwellonit.taterunino.net/

Totally seconded. That's very nice - it's almost like using fog to hide
a draw distance limit. As the human eye sees things blurrier as they get
further away, it seems like a healthy method of bandwidth capping to me.
That way they only fully load those textures that are in view and within
the slider's distance.

--GC


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

2010-10-01 Thread Bryon Ruxton 
> * We change something, and the thing that used to work no longer works
> * People scream that we broke content
> So if we create a call that returns approximate results now, it *always* has
> to return the same results.
Q, in this case, I disagree. Changing the SCRIPT_MEMORY reports later will
not technically break content, it would just requires to slightly alter the
interpretation of it. Modifying the cap variables for event(s) to lower
numbers, is the only things at stake here. If you put the information out on
the wiki right away, as to what to expect of the function in the future. I
would see no valid reason for anyone to whine about such a change later on
if informed prior. The change can also be planned ahead in our code and work
seamlessly with no issues along the way, if you are certain as to what the
changes will be.
(e.g. if the number is not longer a strict multiple of 16, then apply
different rules...done!) As long as it is planned carefully and followed
through to the end goal, that seems fine to me on the short to medium term.
> This is one reason we are reluctant to add new measurements; people come to
> depend on them even when they shouldn't.
Understandable view on your side... but the facts that some people don't
have the proper judgment or skills to rely or analyze statistics accurately,
shouldn't be a reason to deprive those who can use it properly as well as
ethically, with valid and useful reasons for doing so.

On 10/1/10 10:07 AM, "Kent Quirk (Q Linden)"  wrote:

> I don't actually have an opinion about the right answer, but I will note that
> if this is going to be used for things like banning people, then we can't ever
> change it to be something accurate later. The pattern we see is:
> 
> * We build something that has a numeric limit
> * Someone builds something that pushes right to the limit
> * We change something, and the thing that used to work no longer works
> * People scream that we broke content


___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges

Re: [opensource-dev] 2.0 Absolute Dealbreaker - script count feature request

2010-10-01 Thread Erik Anderson 
I hate to break in like this, but we're discussing how inaccurate it is for
Mono scripts to contribute a different multiple than LSL scripts, but in the
end aren't we just counting scripts?  Would it be more accurate to report a
script count and let the user do whatever multiple they want, and then later
when there's a better number out there for memory usage release that as a
new number?  If any assumptions are made by the scriptor at that point they
know where the accuracy lies...
___
Policies and (un)subscribe information available here:
http://wiki.secondlife.com/wiki/OpenSource-Dev
Please read the policies before posting to keep unmoderated posting privileges