SLImageUpload broken / banned client even though it is in the SL wiki?

I regularly use SLImageUpload to upload perfect lossless sculpties.

Currently, despite many blog messages saying that lossless uploads work, SL still does not upload perfect lossless sculpties as they will still suffer from cache recompression. They will appear lossless upon first viewing, but will always suffer cache recompression upon relogging. This is bad because customers and clients cannot be expected to know how to, or be asked to clear their cache and relog, just so they can get a correct rendering of a sculpty.

With SLIU, this cache recompression issue does not happen...SLIU was the best and most reliable alternative to the broken lossless uploads of the main and RC Secondlife clients...but now SLIU is no longer working.

The SLImageUpload client is advertised in the SL Wiki (http://wiki.secondlife.com/wiki/SLImageUpload) but now when I try to log in with it, it gives this:


Error logging in (ban). Secondlife cannot be accessed from this computer.

If you feel this is an error, please contact:
[email]support@secondlife.com[/email]


The alt that I use to upload sculpties via SLIU is in good standing and I can still log it on using the regular client. No matter what, I cannot log in with SLIU anymore. Tried it on a couple different computers using my main and alt accounts, but all report the same error.

Any thoughts? I need to get in touch with Qarl Linden about this but unfortunately his townhall times always conflict with my schedule ;__;

Its broken for me as well - try and contact Eddy Stryker or Pavcules Superior about it, may take a few days but hopefully they will have an answer

I've sent an email and notecard to Qarl so he can hopefully push the right buttons to get logins for SLIU re-opened. He's well aware of the issues of uploading true lossless sculpts and SLImageUpload was the only consistent and reliable alternative.

Let's cross our fingers that it gets fixed. I use SLIU all the time, so I feel like my reliable daily driver has broke down and left me stranded

The slnamewatch bot is giving me the same error starting today. Like you, i am able to log in to the same account using the official client. but not the libsl client.

I have a feeling one of the opensource clients someone developed for spamming recently may have something to do with it. Perhaps they wanted to put a stop to the spam client and overstepped by limiting access to legitimate 3rd party clients.

Added a comment to the ongoing lossless jira
http://jira.secondlife.com/browse/VWR-2404

Could be one of three things. 1) LL is banning certain "thin" clients to hedge themselves from all the bots logging in, and dragging the database to it's knees. Or........

2) The server upgrade borked the channels that thin clients use. Or.......

3) Normal SL borkness.

Take your pick, the result is the same though.

I'll vote for #3, since I just tried it and it worked without any problems at all.


.

seems to be working again, must be SL weirdness...

Works for me I use SL Image Upload a lot. I've seen this same issue occur very rarely a few times. Always it goes away shortly. My guess is that during serious grid attacks, hack attacks, or very high concurrency, LL will disable connections to the grid from certain unconfirmed third party clients until they can sort things out.

However, to keep with the topic, I'll post a tutorial for how to optimize images for compression. Feel free to spread this around in any medium; I encourage it (I still need to get some proper tutorials together.)

File size of JPG2000 images is actual image size, per-channel range of channels used, and range of unique color values. JPG2000 lossless has compression, it just is lossless. On the extreme end of uncompressability would be an image of color static with every pixel a unique value and wide variation between adjacent pixels. On the extreme end of compressibility would be a solid black image

Most sculpts spat out from 3D programs and tools have "extra" information not used. The default apple is an example of this:


Here is the same sculpt optimized for compression (extraneous values thrown out):


Bad apple is 7.58 kb via SL Image Upload (SLIU), whereas fixed apple is 5.56 kb. They create the exact same sculpt. The lossless bug hits around 6-7 kb, so fixed_apple is vastly preferable.

Here are the steps to optimize any sculpt in photoshop:

1) Save the image below to your HD and open it and your sculpt in PS. Resize your sculpt using nearest neighbor sampling to 128x128 if needed, then copy it is it is an actual layer and not the background (Delete the background.) Then add the pixel sampling template as a new layer.

http://img378.imageshack.us/img378/8135/sculptsamplingtemplatete2.png

Your setup should look something like this: http://img378.imageshack.us/img378/2456/comptut1jy4.jpg

2) Make the sampling template the active layer, and use the magic want tool with 0 tolerance and antialias unchecked to select the entire black region. Make the sculpt layer the active layer and press delete.

This is what you should get:
http://img146.imageshack.us/img146/4801/comptut2rv4.jpg

3) press control A to select all, then alt drag (copy) the layer to the _right_ twice to fill three columns of pixels. Select again, then alt drag (copy) the layer _up_ twice to fill three rows of pixels.

This should be your result:
http://img396.imageshack.us/img396/9185/comptut3pe1.jpg

4) Select all, then deselect the top row of pixels. Move the selection up one pixel to completely fill the columns. Select all again, then deselect the right column of pixels. Move the selection right one pixel to completely fill the entire image.

Your result should be the above fixed apple Now, why do you need to do the strange steps to fill the sculpt image? Because the sphere and cylinder sculpt type actually has 32x33 verts, and plane 33x33. The "extra" 33rd rows and columns of verts are smooshed as the final rows/columns of pixels on the top and right of the image. So this method will make sure that you do not waste any vertices.

Now, upload using SLIU. If the file size is more than 6 kb approximately when you upload it, resize the sculpt to 256x256 pixels using nearest neighbor resampling, then upload it. 256x256 images tend to be twice as large in file size as 128x128's, despite having four times the pixels. This is due to retained efficiencies in compression.

Great information Aminom, that helps explain a lot of stuff for me too.

I am fairly attached to SLImageUpload so when it stops working I get a little worried lol since before I started using it, every single sculpt I made was complete garbage. It was only SLImageUpload that increased my interest in sculpts making me believe I could actually make one that didnt look like a wad of crumpled up paper (regardless of its original shape) because back when I first used it the difference was really night and day. Currently, I have noticed SL is getting a little better on the lossless compression uploads - at least in the RC clients. I do check regularly to see the differences by uploading both ways and it is getting closer, but for some things SLIU is still the preferred choice when it comes to sharp details - now I know why.

Good stuff!

I've been following this sculpty-from-cache problem and there is one thing I don't understand. If the problem lies with sculptmaps loading from cache, why would this SLImage Upload program work any better than uploading with the normal clients?

Does it somehow effect the final image file on the SL servers?

I think it is because SL Image Upload uses a different (better) compression algorithm that results in smaller files. IIRC, SLIU uses openjpg2000, whereas LL uses the commercial version.

Oh I see. The compression actually happens client side? That makes more sense, then. I had assumed that the compression happened on the server.