It appears the viewer makes a couple separate requests for each image with different parameters.

I think what will fix this is a rewrite of the way image requests are done since mapimages appear to be requested in chunks and re-assembled in the viewer (which is why you get a blurry image at first, then as the other chunks come in it gets clear).

In my testing, it seems that the priority is simply the priority that it wants them in and the discard level seems to be...

-1 : Someone mentioned that this is a 'cancel request', however after further evaluation this might actually be 'download the JPEG2000 header so we can figure out how many discard levels the image has'.

6-0 : Discard levels from highest discard to full quality.

<conjecture from testing>
The simulator seems to keep track of the byte offsets of the frames and not send an entirely new image. My guess, is it gets this information in the header of the JPEG image. Sending a new image from the simulator at a lower numeric discard level corrupts the image on the client if it has received a image with a higher numeric discard level.

The client tends to send request discard levels in the following order, however the second and third discard varies but is always in descending order.

-1( header? )
5 ( low quality )
2 ( higher quality )
0 ( full quality )

When a client requests a 2 discard level, the simulator sends up to and including that discard level but not (1 or 0). Then when a client requests discard level 1, the simulator only sends the 1 discard level frame because the client already received 6-2.

I think the fact that when a client sends any discard level, opensimulator sends the full quality version, it works and displays properly in the client is proof that the method is something along those lines(Server sending requested frames in byte offsets). In the client, you'll see it tile in at lower qualities first, as the image is downloading. Once it's downloaded it displays the full quality version.

If you didn't want to tweak the use of OpenJPEG, you can probably simply keep the received image bytes in a variable and the last requested discard level. Request images at multiple discard levels then when the image request is done downloading and the discard level is 0, you can fire the 'got image' delegate.

If you wanted to tweak the use of OpenJPEG, then you're probably looking at playing with the values of;

opj_dparameters_t
cp_layer is supposedly the number of highest resolution levels to be discarded.
cp_reduce is supposedly the maximum number of quality layers to decode.
cp_limit_decoding supposedly allows the decoding of the header only.

These get set to 0(not used) in opj_set_default_decoder_parameters(&dparameters) line 213 of libsl.cpp
This would allow you to fire a 'got image' delegate at each of the requested discard levels.

Robin Cornelius t

Hi Everyone,

Can someone confirm exactly how the "RequestImage" message works:-

>From the discussions on #sldev open the openjpeg issues, it appears
that a RequestImage message is sent with a requested discard the
server then fires a bunch of messages back with the image data. It
appears that the server is making the same discard factor assumptions
as the viewer eg that dreaded 0.125 factor so the server decides how
much data to fire for a given discard level then stops when it thinks
it has sent enough.

If the viewer is hacked so it knows not to try to run a decode when
clearly not all the packets have arrived it only fetches one
additional packet every 15 seconds (LAZY_FLUSH_TIMEOUT) which is why
maps etc can take 20 minutes to download.

There are some additional observations here:- The production viewer
has a LAZY_FLUSH_TIMEOUT of 10 seconds not 15 as the released source
code shows.(there is a 10 in the comments).

Secondly KDU we know behaves differently to OpenJPEG, BUT it appears
that if KDU gets an incomplete data for discard *i think* it deletes
the LLRawImage and thus causes the texture fetch to continue gathering
packets. This also takes ages as its only pulling in packages at 10
second intervals (LAZY_FLUSH_TIMEOUT again). But no one really notices
this as the map just displays at the next best discard of 128x128
until all the packets have arrived. But if you sit and watch the
texture console I can observe this behavior and it still takes about
20 minutes for some maps to get to 256x256.

I'm not quite sure what happens in the kdu decode (thats why i said i
think above, not watched the code return paths there yet) but we know
that somehow the texture fetcher keeps running. Carjay's patch makes
the openjpeg decoder not barf at incomplete streams when you request
discard of 0 (Woot!) but we also need to keep the texture fetcher
running somehow to get the full image downloaded and it would be
really cool if this remaining download was not on a fallback code
path.

Regards

Robin
________

<-- 8.2.32.111:12035 10062 [Ack Rel ]
— MapBlockReply —
– AgentData –
AgentID: 32939971-a520-4b52-8ca5-6085d0e39933
Flags: 0
– Data –
X: 890
Y: 1033
Name: Seacrets
Access: 21
RegionFlags: 0
WaterHeight: 0
Agents: 0
MapImageID: 998cfefa-1fff-3412-3239-b02e4c3adb35
– Data –
X: 891
Y: 1034
Name: Lunasea
Access: 21
RegionFlags: 0
WaterHeight: 0
Agents: 0
MapImageID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec

--> 8.2.32.111:12035 6028 [ Rel ]
— RequestImage —
– AgentData –
AgentID: 32939971-a520-4b52-8ca5-6085d0e39933
SessionID: cf5a33ee-7c00-494d-a30e-fd53572c1ac9
– RequestImage –
Image: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
DiscardLevel: -1
DownloadPriority: 1617534
Packet: 0
Type: 0

<-- 8.2.32.111:12035 11046 [ Rel ]
— ImageData —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Codec: 2
Size: 78743
Packets: 80
– ImageData –

<-- 8.2.32.111:12035 11047 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 1
– ImageData –

<-- 8.2.32.111:12035 11048 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 2
– ImageData –

<-- 8.2.32.111:12035 11053 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 3
– ImageData –

<-- 8.2.32.111:12035 11054 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 4
– ImageData –

<-- 8.2.32.111:12035 11055 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 5
– ImageData –

<-- 8.2.32.111:12035 11056 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 6
– ImageData –

<-- 8.2.32.111:12035 11057 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 7
– ImageData –

<-- 8.2.32.111:12035 11058 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 8
– ImageData –

– RequestImage –
Image: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
DiscardLevel: -1
DownloadPriority: 0
Packet: 0
Type: 0

<-- 8.2.32.111:12035 11059 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 9
– ImageData –

<-- 8.2.32.111:12035 11060 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 10
– ImageData –

<-- 8.2.32.111:12035 11061 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 11
– ImageData –

<-- 8.2.32.111:12035 11062 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 12
– ImageData –

<-- 8.2.32.111:12035 11063 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 13
– ImageData –

<-- 8.2.32.111:12035 11064 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 14
– ImageData –

<-- 8.2.32.111:12035 11065 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 15
– ImageData –

<-- 8.2.32.111:12035 11066 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 16
– ImageData –

<-- 8.2.32.111:12035 11067 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 17
– ImageData –

<-- 8.2.32.111:12035 11068 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 18
– ImageData –

<-- 8.2.32.111:12035 11069 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 19
– ImageData –

<-- 8.2.32.111:12035 11074 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 24
– ImageData –

<-- 8.2.32.111:12035 11076 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 26
– ImageData –

<-- 8.2.32.111:12035 11078 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 28
– ImageData –

<-- 8.2.32.111:12035 11083 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 33
– ImageData –

--> 8.2.32.111:12035 6083 [ Rel ]
— RequestImage —
– AgentData –
AgentID: 32939971-a520-4b52-8ca5-6085d0e39933
SessionID: cf5a33ee-7c00-494d-a30e-fd53572c1ac9
– RequestImage –
Image: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
DiscardLevel: 5
DownloadPriority: 1617534
Packet: 1
Type: 0

<-- 8.2.32.111:12035 11179 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 1
– ImageData –

--> 8.2.32.111:12035 6528 [ Rel ]
— RequestImage —
– AgentData –
AgentID: 32939971-a520-4b52-8ca5-6085d0e39933
SessionID: cf5a33ee-7c00-494d-a30e-fd53572c1ac9
– RequestImage –
Image: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
DiscardLevel: 1
DownloadPriority: 1617534
Packet: 2
Type: 0

<-- 8.2.32.111:12035 12665 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 2
– ImageData –

<-- 8.2.32.111:12035 12666 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 3
– ImageData –

<-- 8.2.32.111:12035 12667 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 4
– ImageData –

<-- 8.2.32.111:12035 12668 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 5
– ImageData –

<-- 8.2.32.111:12035 12669 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 6
– ImageData –

<-- 8.2.32.111:12035 12670 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 7
– ImageData –

<-- 8.2.32.111:12035 12671 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 8
– ImageData –

--> 8.2.32.111:12035 6554 [ Rel ]
— RequestImage —
– AgentData –
AgentID: 32939971-a520-4b52-8ca5-6085d0e39933
SessionID: cf5a33ee-7c00-494d-a30e-fd53572c1ac9
– RequestImage –
Image: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
DiscardLevel: 1
DownloadPriority: 1617534
Packet: 9
Type: 0

<-- 8.2.32.111:12035 12694 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 9
– ImageData –

– RequestImage –
Image: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
DiscardLevel: 0
DownloadPriority: 1117534
Packet: 10
Type: 0

<-- 8.2.32.111:12035 13121 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 10
– ImageData –
<-- 8.2.32.111:12035 13122 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 11
– ImageData –

<-- 8.2.32.111:12035 13123 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 12
– ImageData –

<-- 8.2.32.111:12035 13124 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 13
– ImageData –

<-- 8.2.32.111:12035 13126 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 15
– ImageData –

<-- 8.2.32.111:12035 13129 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 18
– ImageData –

<-- 8.2.32.111:12035 13130 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 19
– ImageData –

<-- 8.2.32.111:12035 13131 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 20
– ImageData –

<-- 8.2.32.111:12035 13132 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 21
– ImageData –

<-- 8.2.32.111:12035 13140 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 22
– ImageData –

<-- 8.2.32.111:12035 13141 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 23
– ImageData –

<-- 8.2.32.111:12035 13142 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 24
– ImageData –

<-- 8.2.32.111:12035 13143 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 25
– ImageData –

<-- 8.2.32.111:12035 13144 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 26
– ImageData –

<-- 8.2.32.111:12035 13145 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 27
– ImageData –

<-- 8.2.32.111:12035 13146 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 28
– ImageData –

<-- 8.2.32.111:12035 13147 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 29
– ImageData –

<-- 8.2.32.111:12035 13148 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 30
– ImageData –

<-- 8.2.32.111:12035 13149 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 31
– ImageData –

<-- 8.2.32.111:12035 13150 [ Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 32
– ImageData –

<-- 8.2.32.111:12035 11070 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 20
– ImageData –

<-- 8.2.32.111:12035 11071 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 21
– ImageData –

<-- 8.2.32.111:12035 11072 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 22
– ImageData –

<-- 8.2.32.111:12035 11073 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 23
– ImageData –

<-- 8.2.32.111:12035 11075 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 25
– ImageData –

<-- 8.2.32.111:12035 11077 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 27
– ImageData –

<-- 8.2.32.111:12035 11079 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 29
– ImageData –

<-- 8.2.32.111:12035 11080 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 30
– ImageData –

<-- 8.2.32.111:12035 11081 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 31
– ImageData –

<-- 8.2.32.111:12035 11082 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 32
– ImageData –

<-- 8.2.32.111:12035 13125 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 14
– ImageData –

<-- 8.2.32.111:12035 13127 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 16
– ImageData –

<-- 8.2.32.111:12035 13128 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 17
– ImageData –

<-- 8.2.32.111:12035 13151 [ Res Rel ]
— ImagePacket —
– ImageID –
ID: b58d6db1-eae8-6206-ae1e-2d9ab3174cec
Packet: 33
– ImageData –

after re-reading Robin's comments I grabbed off the sldev mailing list, it appears the fix we did tonight is actually pretty close to how the viewer works, at least timing wise, although it takes far less than 20 minutes for us to get. We could possibly add a turbo mode timer to make it faster, but I'm satisfied that what we've got working is at least as good as the viewer less the ability to display the image with less resolution mid-download. I am guessing the simulator is throttling the speed of the packets which is silly, but I can understand it being that way considering in the viewer you could be viewing up to several hundred map images at a time (downloading them).

Thanks for looking into this issue with me, glad to have this one behind us!

Jim