Talk:GridImageUpload - Revision history

Mackseem Dejavu: moved Talk:SLImageUpload to Talk:GridImageUpload

2009-12-06T15:46:32Z

moved Talk:SLImageUpload to Talk:GridImageUpload

← Older revision	Revision as of 08:46, 6 December 2009
(No difference)

Mimika Oh: Adding failure report for Mac OS X.

2008-08-16T17:47:14Z

Adding failure report for Mac OS X.

← Older revision		Revision as of 10:47, 16 August 2008
Line 1:		Line 1:
			Fails on Mac OS X 10.5.4. Installed Mono 1.9.1_3. Installed SLImageUpload 1.0.3. When I try to "Load Texture" I just get a dialog saying "System.DIINotFoundException: libopenjpeg-libsl-2.1.3.0.dylib".

			----

	I am having issues with 'some' images.		I am having issues with 'some' images.

Ina Centaur: New section: Why Not in Inventory?

2007-12-03T03:40:25Z

New section: Why Not in Inventory?

← Older revision		Revision as of 20:40, 2 December 2007
Line 31:		Line 31:

	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. --[[User:Eddy Stryker\|Eddy Stryker]] 02:45, 26 October 2007 (PDT)		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. --[[User:Eddy Stryker\|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?

Eddy Stryker: Moved a comment here and followed up on it

2007-10-26T09:45:27Z

Moved a comment here and followed up on it

← Older revision		Revision as of 02:45, 26 October 2007
Line 10:		Line 10:

	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)		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. --[[User:Eddy Stryker\|Eddy Stryker]] 02:45, 26 October 2007 (PDT)

Eddy Stryker at 01:57, 6 September 2007

2007-09-06T01:57:27Z

← Older revision		Revision as of 18:57, 5 September 2007
Line 6:		Line 6:

	Any idea??		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)

Okham Reddevil: New page: 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 ...

2007-08-07T17:46:52Z

New page: 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 ...

New page

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??