Talk:GridImageUpload

I am having issues with 'some' images.

In general, the tool works; with some small pics the upload is succesful, but once in the client, trying to apply the texture on a prim will result in a missing image error.

I could not put the finger on the real error yet.

Any idea??

---

What are the dimensions of the images? Do they show up correctly in the thumbnail preview in SL Image Upload? If so, what file size is shown? Are these three or four component images (ie, do they have an alpha layer)? Are you able to post a source image online that exhibits this behavior? --18:57, 5 September 2007 (PDT)

---

This program may alter images, but it is disputed. It is known that various parts of the image delivery path (the way the image is delivered *back* to your client) can often alter the image before you see it, so even if SLImageUpload does a good job with lossless uploading, SL and the SL client are known to damage the image on the way back to you. Sometimes. Qarl Linden is very tuned in to this entire issue, and promises a fix that is currently being tested. Regardless of source, the effect can be seen fairly easily when uploading low resolution (e.g. 32x32) images losslessly with solid gray boarders around colored blocks. When you see it used in your client, it will look very blurry, despite being uploaded losslessly. Interestingly, the cache system of the SL client also damages images, and clearing your cache can (temporarily) improve the image quality. The effects are varied, and not all images are affected noticibly.

The Maya lossless uploader by the same author does appear to upload losslessly without corruption (we tested it).

It can be downloaded from: http://www.jhurliman.org/download/importprimscript-1.0.2.zip

With some work it may be usable as an alternative to this program. The uploading executable itself does not require Maya.

For more information, see: https://jira.secondlife.com/browse/VWR-866 and http://jira.secondlife.com/browse/VWR-2404

---

I've seen the example prims (they are still rezzed in the libsecondlife sandbox) and they demonstrate the problem above, but I think the statement about one program not having a problem and the other having the problem is misleading. importprimscript uses the exact same compression and upload functions in libsecondlife that SLImageUpload uses, and because the old version of SLImageUpload had a bug where checking the lossless checkbox didn't always enable lossless compression I'd like to see some further investigation here. I know the client can still request lower LODs with texture requests (not sure if the server actually creates these lower LODs out of lossless images or tells the client it can't have it), and I believe it can also create lower LOD textures by itself (but not positive on that part). Either way, ideally you would hope that wouldn't be happening with a 32x32 image but who knows. I need to release an SLImageDownload tool so people can grab raw JPEG2000 data from Second Life and confirm the properties with the Kakadu or OpenJPEG viewers. --Eddy Stryker 02:45, 26 October 2007 (PDT)

Why Not in Inventory?

I'm a bit confused at why the uploaded texture doesn't show up in inventory, and that only UUID is available. Since L$10 is paid and a real SL account must be used to log in, shouldn't uploading the texture mean that the texture is dropped in the corresponding inventory?

Or, is there some sort of relationship between the standard viewer and uploads-to-appear-in-inventory?