On 2010-09-13, at 07:22, Leonel Morgado wrote:
> Notice that old JPG does not support alpha channels (transparency). That
> means abandoning JPEG2000 would in fact force everyone with a single
> transparent pixel (even if just corners of round textures) to use lossless
> PNG for that, which is not
Hi,
Very interesting discussion though it seems that folks collide several
things when talking about "textures" in general terms: there's a load of
difference between a repetitive 64x64 texture used to tile a brick wall and
a photographic quality 1024x1024 texture. The former could certainly benef
ssage-
> From: opensource-dev-boun...@lists.secondlife.com
> [mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Argent
> Stonecutter
> Sent: segunda-feira, 13 de Setembro de 2010 13:15
> To: Tateru Nino
> Cc: opensource-dev@lists.secondlife.com
> Subject: Re: [o
-Original Message-
From: opensource-dev-boun...@lists.secondlife.com
[mailto:opensource-dev-boun...@lists.secondlife.com] On Behalf Of Argent
Stonecutter
Sent: segunda-feira, 13 de Setembro de 2010 13:15
To: Tateru Nino
Cc: opensource-dev@lists.secondlife.com
Subject: Re: [opensource-dev] J2C fast
On 2010-09-13, at 00:40, Tateru Nino wrote:
> If we're using HTTP textures, is there actually any need for the JPEG 2000
> format? Since the transfer time of individual textures is vastly reduced
> (from the first byte to the last byte) the intermediate quality levels
> supported by jpg2k would
under active development?
Sheet Spotter
--
*From:* opensource-dev-boun...@lists.secondlife.com [
mailto:opensource-dev-boun...@lists.secondlife.com]
*On Behalf Of *Philippe (Merov) Bossut
*Sent:* September 9, 2010 10:35 PM
*To:* Nicky Fullton
*Cc:* opensource-dev@lists.secondlife
On Mon, Sep 13, 2010 at 12:24 AM, Tateru Nino wrote:
> Wouldn't we be making a network saving by omitting the discard levels
> entirely? Granted, I don't have hard data about that - would the base
> texture encoded in a lighter-weight format end up causing less data to
> traverse for a given textu
ght not support progressive decoding.
>>
>> http://jira.secondlife.com/browse/SNOW-361
>>
>>
>>
>> Is an upgrade to OpenJPEG v2 under active development?
>>
>>
>>
>>
>>
>> Sheet Spotter
>>
>>
>> -
secondlife.com>
[mailto:opensource-dev-boun...@lists.secondlife.com] *On Behalf
Of *Philippe (Merov) Bossut
*Sent:* September 9, 2010 10:35 PM
*To:* Nicky Fullton
*Cc:* opensource-dev@lists.secondlife.com
<mailto:opensource-dev@lists.secondlife.com>
*Subject:* Re: [op
ilto:opensource-dev-boun...@lists.secondlife.com]
> *On Behalf Of *Philippe (Merov) Bossut
> *Sent:* September 9, 2010 10:35 PM
> *To:* Nicky Fullton
> *Cc:* opensource-dev@lists.secondlife.com
> *Subject:* Re: [opensource-dev] J2C fast decoder
>
>
>
> Hi Nicky,
>
> As
On Sun, Sep 12, 2010 at 10:40 PM, Tateru Nino wrote:
> If we're using HTTP textures, is there actually any need for the JPEG 2000
> format?
There is the 500TB asset server full of jpeg2k images. Switching to a
new format would be a massive undertaking.
> Would it be a huge problem, for example,
*Sent:* September 9, 2010 10:35 PM
*To:* Nicky Fullton
*Cc:* opensource-dev@lists.secondlife.com
*Subject:* Re: [opensource-dev] J2C fast decoder
Hi Nicky,
As it happens, I've been working on instrumenting the code to add
metric gathering for image decompression as part of the Snowstorm sprint.
Yo
e-dev-boun...@lists.secondlife.com] *On Behalf Of *Philippe (Merov)
Bossut
*Sent:* September 9, 2010 10:35 PM
*To:* Nicky Fullton
*Cc:* opensource-dev@lists.secondlife.com
*Subject:* Re: [opensource-dev] J2C fast decoder
Hi Nicky,
As it happens, I've been working on instrumenting the code to add met
: [opensource-dev] J2C fast decoder
Hi Nicky,
As it happens, I've been working on instrumenting the code to add metric
gathering for image decompression as part of the Snowstorm sprint.
You may want to use my branch
(https://bitbucket.org/merov_linden/viewer-development-vwr-22761) and cre
Hi Nicky,
As it happens, I've been working on instrumenting the code to add metric
gathering for image decompression as part of the Snowstorm sprint.
You may want to use my branch (
https://bitbucket.org/merov_linden/viewer-development-vwr-22761) and create
a baseline for openjpeg then run a test
Altair Sythos Memo wrote:
> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
> images, after a short test with openjpeg2000 from EPFL we have tested
> last 3 days JasPer (only a POC apps to do some bench), we must do a lot
> of work too, but this is a lil question... anybody he
Hello,
>> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
>> images, after a short test with openjpeg2000 from EPFL we have tested
>> last 3 days JasPer (only a POC apps to do some bench), we must do a lot
>> of work too, but this is a lil question... anybody here around neve
On Wed, 25 Aug 2010 22:06:00 +0100
Robin Cornelius wrote:
> I'm not aware of anyone publishing results for such a test, but if you
> have the time it would be interesting reading. Some things to keep in
> mind. OpenJpeg has patches floating around on its ML against 1.3 that
> reports have claime
-BEGIN PGP SIGNED MESSAGE-
Hash: SHA1
On 8/25/2010 2:06 PM, Robin Cornelius wrote:
> Also in SL usage, (please correct me if i am wrong) when the viewer
> ups the resolution (using discard levels) openjpeg needs to redecode
> the entire image, KDU does not, and the meta data extraction for
On Wed, Aug 25, 2010 at 10:00 PM, Altair Sythos wrote:
> i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
> images, after a short test with openjpeg2000 from EPFL we have tested
> last 3 days JasPer (only a POC apps to do some bench), we must do a lot
> of work too, but this i
i'm testing in RL office (not or a viewer) JasPer decoder for JPG2000
images, after a short test with openjpeg2000 from EPFL we have tested
last 3 days JasPer (only a POC apps to do some bench), we must do a lot
of work too, but this is a lil question... anybody here around never
tried it as altern
21 matches
Mail list logo
