[sldev] Meaning of RequestImage DiscardLevel field?

[John Hurliman]

Thank you for the info Teravus. It seems reasonable that -1 would be a
default value that defaults to the lowest discard level available, or the
previously set discard level if the client has already requested a specific
one. I think the best approach at this point is going to be a libomv app to
do lots of guess and check work. I'll post back when I find out more.

John

On Thu, Sep 25, 2008 at 7:40 PM, Teravus Ovares <teravus at gmail.com> wrote:

> Once again, I know this is speculation..    however I ran some tests
> on this a few months back.   I attempted to send the discard levels as
> individual images, and the first discard level requested came through,
> however, subsequent 'images' sent representing the next level of
> discard level caused it to corrupt the image client side.    This
> leads me to believe that the discard levels represent byte offsets of
> where the boundary between the packets that represent the discard
> levels are..   as far as the server is concerned.   So, in other
> words..   lets say you have 5 discard levels in an image.
>
> You'd have to know this before hand in meta data or decode it on the fly.
>
> The client asks for discard level 5...      We send it bytes 0-1000.
> The client asks for discard level 3 of the same image..    we know it
> has already received the discard level 5 bytes..     so we send bytes
> 1001-5000.
>
> ..   and we keep appending the rest of the file based on the packets
> in the file
>
> This implies that the packets are ordered in sequence from lowest at
> the beginning to highest at the end.
>
> Sometimes we get requests on the simulator for -1 before the rest of
> the discard levels are requested.
>
> Sometimes we get requests on the simulator for -1 when the third
> discard level is requested..       It seems to have to do with
> defining and keeping image priority.
>
> On a Linden Simulator, it appears that there's an image priority queue
> that it uses to feed the clients images at different discard levels
> and keep track of the ones it has previously sent.   It also seems to
> reorder them in the priority 'list' that the server keeps.
>
> But!, it would be nice to get a LL Developer's view on what Discard
> Level actually represents.
>
> Best Regards
>
> Teravus
>
> On 9/24/08, Salvador Agati <agati at procele.com.br> wrote:
> >
> >
> >
> > ----- Original Message -----
> > From: John Hurliman
> > To: Carsten Juttner
> > Cc: Second Life Developer Mailing List
> > Sent: Sunday, September 21, 2008 1:05 AM
> > Subject: Re: [sldev] Meaning of RequestImage DiscardLevel field?
> >
> >
> > Thank you Carsten, that clarification is correct. For now I'm assuming
> that
> > DiscardLevel 0 is a request for the full quality (zero discarded levels)
> and
> > DiscardLevel 5 is requesting the lowest quality level. However, if you
> start
> > with five quality layers and you discard five of them what are you left
> > with? Is five actually being clamped to four? This still doesn't explain
> -1.
> > If you send a RequestImage with Priority = 0.0 and DiscardLevel = -1 it
> will
> > cancel the download, but texture requests often start with a positive
> > priority and a DiscardLevel of -1. Is this a request for the header only,
> or
> > is it just an uninitialized value in the client that implies zero or
> four?
> >
> > John
> >
> >
> > On Fri, Sep 19, 2008 at 3:45 PM, Carsten Juttner <carjay at gmx.net> wrote:
> > >
> > >
> > > Robin Cornelius wrote:
> > >
> > > John Hurliman wrote:
>
> > >
> > > I know that the DiscardLevel field in the RequestImage packet is used
> > to
> request different quality levels (not different texture sizes as
> > the
> protocol documentation states, SL uses LRCP ordered JPEG2000 files),
> > but
> i can't figure out what the values correspond to. In a typical
> > texture
> download I'll see values ranging from -1 to 5. Is -1 a special
> > value? Is
> there an upper limit? Does a larger number mean a lower quality
> > layer?
>
>
> > > The discard field is directly related to the request quality level as
> you
> > are already aware. It should be a simple calculation that the
> discard is the
> > number of powers of 2 to scale the image down by for the
> reduced quality. So
> > a discard of 0 is the complete image and a discard
> of 1 is a 1/2 size, a
> > discard of 2 is a 1/4 size etc.
>
> > >
> > > I think what John was actually referring to here is that quality layers
> > and resolution levels are not the same. In JPEG2k all data is divided
> into
> > packets for one tile. Each packet contains codestream data for one
> quality
> > layer for one resolution for one component for one precinct (spatial
> > partition). The order in which you transmit the packets decides what you
> get
> > first and is signalled by the "progression order". LRCP
> > (Layer-Resolution-Component-Position) is layer-centric
> > meaning that one by one you get all the data for each quality layer, not
> for
> > each resolution. That means you end up with the lowest quality layer for
> all
> > resolutions first so it's really a quality-based progression, not a
> > resolution-based.
> > >
> > > Think of the quality layers as going down the bits from MSB to LSB.
> First
> > you get the rough information, then it progresses to the detailed
> > information (actually for the wavelet coefficients).
> > >
> > > AFAIK, inside the viewer the progression order is not really cared
> about
> > and the discard levels are merely referring to the dropped resolutions
> from
> > the highest resolution.
> > >
> > > Also nobody seems to really know what is happening on the server side
> > since we did ask a while ago but never met a Linden who was familiar with
> > that area of the code so it's still a bit of a mystery.
> > >
> > > Regards,
> > > Carsten
> > >
> > >
> > >
> > >
> > > I'm not used to post here and I' ve got only these 2 messages above
> > related to the subject. Indeed , english is not my native language and I
> am
> > concious that I'm not an expert as you, in this list,  are.
> > >
> > > Despite of that, I decided to send this post because one of the first
> > things I noted when I began to discover SL was exactly the way images
> were
> > loaded in the viewer.
> > >
> > > It reminded me when I,  after the college, was a mastering student and
> had
> > to read and discuss, in the class, the implementation of  an algoritm . I
> > happened at about 20 years ago.
> > >
> > > In this book, it was presented an algoritm called "gross information
> > first" and it used in the formula,  power of 2 numbers to calculate the
> > pixel value of a group of pixels of a image.  So, the quality of the
> image
> > generated with the algoritm was related to 2, 4, 8, 16, 32 or thinking as
> > power of 2,  the values 0,1,2,3,4,5 .
> > >
> > > I was wondering if this is the case, where the viewer asks for the next
> > quality layer after the previous layer loaded and -1 to ask for data
> without
> > this type of filtering.
> > >
> > > In this situation, the image, in the server, would  be stored only with
> > the highest quality and the server would  first "filter" the image, with
> the
> > correct factor, and then,  send it to the viewer, progressively, as
> > requested.
> > >
> > > If someone call me crazy , I won't deny.
> > >
> > > Regards,
> > > Agathos Frascati SL
> > > Salvador Agati RL
> > >
> > >
> > >
> > >
> > >
> >
> > _______________________________________________
> > Policies and (un)subscribe information available here:
> > http://wiki.secondlife.com/wiki/SLDev
> > Please read the policies before posting to keep unmoderated posting
> > privileges
> >
>
-------------- next part --------------
An HTML attachment was scrubbed...
URL: http://lists.secondlife.com/pipermail/sldev/attachments/20080928/f69cca22/attachment.htm