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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 <[EMAIL PROTECTED]> 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 > > >
_______________________________________________ Policies and (un)subscribe information available here: http://wiki.secondlife.com/wiki/SLDev Please read the policies before posting to keep unmoderated posting privileges
