It then gets resized to the target dimensions of 1024 BEFORE it is sent to the lab. All that is happening in this example is that the source image that you are allowed to specify in the uploader can be larger than the default 2048. The lab strictly enforces the resolution of ALL image uploads. *You cannot upload high than 1024x1024 - try it yourself* It seems that misinformation rules the day. Sadly, while the observations here are correct the post is just as full of misinformation as the earlier post that Whirly and I took time to try to correctly explain. The viewer upload/compression/resize clearly reduces quality much more when uploading the 1024 image then it does when uploading the 8192 image.Īnd there's a whole forum thread on this from Beq Janus going into further detail, and there's even more detail and discussion in the original post's Comments thread. Photoshop did a fine job at resizing the texture. It's pretty obvious the 8192 texture on the left is better quality even though both images after upload are 1024x1024.Īlso note that the Photoshop resized 1024 image does not have all the compression artifacts you can see in the right uploaded texture when viewed in Windows photo viewer. On the right is the same PNG reduced to 1024 in Photoshop using Bicubic Sharpen (best for reduction) before upload. On the left is the original 8192 PNG image uploaded by changing the debug settings. This image shows 2 textures uploaded on the LL viewer side by side viewed in the texture preview floaters. If you upload a 8192 (allowed by changing those debug settings) the viewer will apply the same lossy compression, except this time it has 8 times the quality on input with which to work.Īlso to note, using this trick will not cause any extra "lag" - the uploaded 8102 x8192 image is still 1024x1024 after upload. If you upload a 1024, the j2k compression goes through and does lossy compression on the data you give it. You give the viewer a texture to upload & it's converted to a 1024x1024 j2k texture (JPEG 2000). I asked one of the Firestorm developers what was going on here & they are still investigating, but initially the thought is that this trick has more validity then it first seems. I'm quite surprised the uploader makes a better job of the resize then Photoshop tbh. The 8192 texture resized by the uploader is much sharper, has less noise & the highlights pop more then the texture that was 1024 before upload. Fizzle, including a sample comparison images they took:Ĭompare these 2 uploaded textures side by side. Set the debugs max_texture_dimension_X and max_texture_dimension_Y back to default & upload your image. Now open your 8192 PNG in Photoshop & reduce the image size to 12.5% using the Bicubic Sharpen (best for reduction) & save this image. This image will upload and the uploader will resize the image to the maximum allowed size of 1024x1024 - this limit is enforced server side, there is no way around it. Set the debugs max_texture_dimension_X and max_texture_dimension_Y to 8192. Get hold of a super high quality 8192 image with lots of fine detail & make sure it's saved in a lossless format - I used PNG in my test. Those debug settings are from the Linden Lab viewer, they are not Firestorm specific. This will also work just as well on the Linden Lab viewer & probably every other viewer. But Frenchbloke is actually correct! The blog post just explains it badly. When I first read this blog post I thought it was a load of cobblers. (My bad and mea culpa!) However, Firestorm support and QA volunteer Whirly Fizzle came by Comments, and confirmed that this does, indeed, apparently work: Last week's post on improving SL image quality via a workaround from SLer Frenchbloke Vanmoer caused a lot of skepticism, mostly due to some poor technical wording on my part.
0 Comments
Leave a Reply. |