Image upload: Downscale Large Images
tracked
Signal Linden
Allow the viewer to downscale images larger than its current limit of 2048px down to Second Life's max image size of 1024.
Rationale
High resolution images are rather common, especially with the proliferation of 4, 5 and 8k monitors. It is onerous to resize images manually before they can be uploaded to Second Life.
Log In
Talia Tokugawa
Okay I have a use case and a potential alternative solution.
You went to all the trouble of implementing the images for folders feature which is great but it's seriously hamstrung by the image size limitations. Say you have a decent clothes maker who goes to the trouble of including the sales texture with the clothes. Makes sense and I really appreciate it when people do that.
But then due to the size constraint on folder images you end up with this shenanigans..
The worst bit about this is that the image itself is already an inventory image for itself. So, you can certainly work around that constraint. But even copying the existing inventory image and then attempting to past that as the inventory image to the parent folder fails. It makes no sense. Any form of downscaling such as this Should be encouraged. The item of clothing I am trying to sort out is from before the intro of 2056 so it's almost certainly 1024.
Obviously an integrated solution would be best for this..
The current system.. if I don't want to leave SL to actually make it happen. About my only choice is to snapshot..
Another possible option would be to implement https://feedback.secondlife.com/feature-requests/p/uploading-assets-overhaul
You could impletment this.. Then users could create a web app that using the javascript clipboard api to listen for something being added to clipboard. That way you could set a hud device to "listen", use the system screenshot system to drag a region, that screenshot goes to clipboard which the hud picks up sends off to a resizer api. it returns a url of where to upload the resized image from the hud then forces the upload floater prepopulated with that url. The user accepts the payment and bam they have a resized image.
For, click to "listen", keyboard shortcut,click drag, click to accept in terms of user interaction.
Dutch Galaxy
Please add on, to allow the graphics viewer applet in the viewer to 'remember' or 'read' a pictures resolution, whether it be 16:9, 16:10, 5:4, 1:0, etc
Jasdac Stockholm
Can said downscaler come with a dropdown to set X and Y manually? If you're going to resize it anyhow, it'd be a nice QOS feature to save time in an image editor downscaling large textures that you don't need to be 1024x1024.
dantia Gothly
The viewer already downscales large textures down to 1024, if you use the bulk upload option built in to any of the viewers incluiding the LL viewer you can upload any size image and it will be downscaled to 1024 currently. Those images are also converted to JPG2000 reguardless if you use PNG or TGA formats.
People are already charged a fee for uploading so what you seem to be asking for is to have LL pay a 3rd party for a feature that already exists which will cause them to charge a higher fee on creators to upload textures.
I would suggest against it and find another way rather then looking for a paid 3rd party service to do something that already exists. Otherwise your just asking for another reason to drive customers and content creators away from the platform.
Gwyneth Llewelyn
dantia Gothly: The word here is
optional
!Firstly, thanks for confirming that the viewer does already a downscaling of the image. As said, I
was
told that it does, but couldn't reach any reasonable conclusion based on my few examples, so I was unsure if this was an existing feature, an upcoming feature on some beta version I hadn't tested yet, or possibly a feature of a TPV which I didn't test with.So, I'd say, this feature request can be closed with the
Already implemented
tag :)Secondly, I see that you brought up the argument of content creators leaving the platform if they have to pay more for using it. I totally agree. But let's be honest here —
professional
content creators, who are in SL to provide the best possible content they can, in order to make enough sales to draw a regular income (even if it's just a part-time income!), already
know perfectly well how to properly downsize an image for the purpose of using it as a 1024x1024 texture inside SL.They already have their tools (which often cost far more than L$10 😉 ) and, most importantly, they already have their graphics pipeline in place — the sequence of tools they use in order to produce a final image. While this will naturally vary among designers (and the kind of hardware/OS they use), it's expectable that practically everybody taking this seriously will start their work at high resolutions and
know perfectly well
which tool to apply to a specific image to get a "perfect" resize. LL doesn't need to help out these professional content creators; and they couldn't care less about what kind of algorithm or tool LL uses, since it's most likely they will avoid it anyway, and use their
own toolset for best results.No, this is the kind of thing that
might
appeal to those who are not really "professionals" but enjoy doing a bit of creative work and will sometimes upload a texture or two just to see what they can do with it. They might even be familiar with one tool or another, but not proficient with it — or they might have grabbed the image for the texture from elsewhere, or generated via AI, whatever. The point is that such users are neither professional content creators nor even experts with the whole digital art production environment; instead, they rely on simple
tools to get things done.It's also extremely unlikely that such users will upload
tons
of textures that way, so anything which is "freemium" should be more than adequate for them — it's unlikely they'll ever go beyond the daily or monthly allowance of such tools. (Note: I'm always using "them", but I include myself in that group!)Therefore, having an option to put in your API key somewhere to get access to a "better" compression/resizing algorithm is not an outrageous suggestion that will make every content creator suddenly leave SL and run to Roblox or VRChat — those professionals will never use such a service inside the SL Viewer anyway, since they want some
control
over how their content is properly resized, not place it into the hands of some sort of one-size-fits-all algorithm and trust it to do a good job (because it won't).That said, I can see a good argument for
not
using any external third-party tool, which I didn't consider on my previous comment: mistrust of how intellectual property is handled by third parties (where will it be stored while being resized?) and/or limitations in terms of what kind
of content can be uploaded for further processing (since SL has
a vast number of adult and NSFW content).I always remember the story of the pictures taken from statues in the
Vatican
Museum which had been censored because, well, they were deemed to be "obscene" (the statues are "almost naked") — which is the ultimate irony, considering where
those statues had been iRL 😂But sure, jokes beside, it's true that
forcing
anyone to use a third-party library or system or platform that they don't necessarily trust with their content (especially if it's of the adult kind) would be suicide — and I most certainly didn't suggest that
! Rather, I believe it would be far better to use something that has
been proven to work well out there iRL instead of trying to reinvent the wheel.As said, ImageMagick is a good free and open-source library that I can recommend in good conscience. I use its basic features all the time, when I don't really
need
the kind of "perfection" mentioned on a different comment — although ImageMagick can
do that, it requires some experience with its uncountable filters and settings to effectively use it (I'm happy to use the very reasonable defaults). If more quality than that is desired, well, I do
have my own modest pipeline as well, but it really bothers me to go through all its steps (my computer is old and slow...) if I just need a quick resize...Then again, as said,
if the SL viewer already does all the resizing in Bulk mode
then this whole FR is pretty much moot. All that LL needs to do is to use the same code when uploading single images (and why that's not the case is really tough to understand!)Gwyneth Llewelyn
Two things...
1) I was
told
that this already happens, and with admirably good results, namely, less artifacts from downscaling — unless the person in question was confusing the official SL Viewer with a TPV (I could not tell).2) As @SpiritSparrow Skydancer has mentioned, there
is
a perceptible loss of quality on many libraries. I would strongly recommend using TinyPNG for that — I have tried many, many libraries (and settings in those libraries), and nothing comes as close to TinyPNG to image manipulation.TinyPNG is a paid service, with a generous amount of free resizings per month. It could be implemented exactly like the translator options: add your developer key, and if you have a paid TinyPNG account, your restrictions get lifted (exactly as if you'd do it either through their website and/or their REST API).
The next-best alternative I came across was ImageMagick, which does a decent job, but it cannot catch up with TinyPNG's magic, even with extensive parametrisation.
Besides resizing, TinyPNG excels at reducing the overall image size
without any visual quality perception loss
. The best example is taking a "raw", unoptimized PNG and convert it to the way-more-efficient WebP format. It shrinks its byte size down (on average) by thirty times. No, it's not 30% — it's really 30 times. Thus, a PNG taking 3 MBytes in, say, Photoshop will be compressed to a merely 10K WebP file. That's jaw-dropping performance in space saving — and, as said, there is no
perceptive visual loss. Granted, LL internally uses JPEG2000, and, sadly, TinyPNG does not convert directly to JPEG2000, or LL could replace all internal tools doing the crazy file conversions to and from JPEG2000...Yman Juran
Gwyneth Llewelyn: As a performer, who create many posters for events I would really like to see such an idea implemented
SpiritSparrow Skydancer
I'd vote for this. It is very irritating when I try to upload an image I made or have taken.. However, usually with auto downscale the images loose quality. Soo, I'm all for this but, without image quality loss.
Kadah Coba
Please use a good image resize algo for this.
Kuuko Shan
Kadah Coba: Preferably bilinear, to keep details and no't break them. Using something else with enhacement details options could potentitally result in innacurate results, specially for normal maps.
Gwyneth Llewelyn
Kuuko Shan: I'd say,
don't
reinvent the wheel — see my answer above, there are already a few excellent packages (paid, freemium, or fully open source) which do everything and have been thoroughly tested by literally millions of people using them every day. Nobody at LL will wake up in the morning and come up with "the perfect algorithm implementation for our use-case" — and get it right on the first time. It's far safer to use something that we know
that works (it's also far easier to debug, too!) rather than using one of many possible solutions and hoping it works for most cases.Speaking of which, if you do have the time and the patience to read all there is about the subject of resizing algorithms, here is a very extensive article on it: https://imagemagick.org/Usage/filter/ — of course it uses ImageMagick's own implementations to discuss the various aspects of resampling images for resizing them, but it serves to give a very good idea on why there are so many algorithms, and why some are
really
better than others.But to quote the author of that text:
This is extensive, long studied, and often full of opinion and personal views rather than any hard qualitive facts, as it is imposible
[sic] to determine what constitutes a perfect resize image. This is a proven fact, and makes for a very large area of study that will never be finished.
😂
Kuuko Shan
Gwyneth Llewelyn: precisely because you don't need to reinvent the wheel, bilinear will do it. This isn't so much a matter of preferences, it's a fact that you can't use certain algorithms for resizing textures because you are working with linear data which shouldn't be altered, just shrinked.
I think the actual way works perfectly fine, since the viewer seems to already use bilinear. The only needed is to unlock higher resolutions than 2K, which you can already do through debug settings.
About formats, PNG and TGA are perfectly fine and we don't need to seek for smaller formats. It takes 1 second to upload a PNG file, which will be compressed in jpg2000 anyway so to choose a different format it's pointless and would just add to users confusion. PNG is already small enough and it uses lossless compression so you get to keep 100% of the quality. No need for anything else.
So, long story short, the viewer already does all this, just needs to be unlocked to accept higher res images by default without having to tweak any debug setting.
Gwyneth Llewelyn
Kuuko Shan: I concur. If the viewer already does everything (and it's just a question of tweaking a debug setting), there is no point to continue to discuss it here :) Signal Linden you can mark it as fixed :)
Kadah Coba
Kuuko Shan: I use Lanczos when available.
Signal Linden
tracked
Crush Cutie
It would be better to allow 2048 (or higher!) texture maps to help reduce the overall number of image maps needed for larger objects. fewer images means less processing (fetch, decode, etc) per object in the viewer and faster rendering.
High resolution monitors are only going to become more common and that will exert pressure on creators to create content that caters to them. The existing 1024 texture cap simply results in people tiling multiple images, which is the worst outcome. This is happening already and is very common.
If misuse is a concern (2048 textures on earrings, etc) update the texture fetch code. As images are stored as progressive JPEG2000 and can be downloaded in incrementally increasing sizes. The viewer should only fetch the data for a texture size based on screen space used and should unload that data when not needed. (it does the former, im not sure about the later).
Generating smaller low detail images is easy and not consuming all the VRAM with too much image data is a solvable problem.
The goal being to allow those earings to have a full resolution textures (whatever that might be), that wont ever be loaded under normal conditions. If a user zooms in or scales them up, the bigger image is loaded, and that bigger image is stepped back when not needed.
This works well with the amateur nature of content created for SL (textures will always be too big) and offers a way for skilled creators to make better content with fewer overall images.
Kristy Aurelia
Crush Cutie: The issue with that is, in a lot of cases, especially when going between 2048-1024, the downsampled texture will look rather blurry and ugly. It is not as much of an issue when swapping between lets say 256 and 128, because if viewer is using those resolutions, it is likely only small number of pixels of that object are visible anyway. Which will not be the case on large objects.
Also shopping events and large stores will likely end up unbearable - most creators will use the max resolution available for their product posters, which usually include text outlining the features, which in a lot of cases will be too blurry to read, unless fully zoomed in, and with hundreds of products each having a separate texture, in a tight space... that's a lot of loading, unloading, downloading, disk cache invalidation.
Crush Cutie
Kristy Aurelia: 2048 is already on the beta grid, test viewer went out just before xmas.
Kristy Aurelia
Crush Cutie: Am I missing something? If the limit is going to be increased to 2048, why does this issue exists that is to downscale images to 1024?
Very Vanilla
Crush Cutie: As a feasibility test just to see what happens, not as a currently planned feature- not adding that bit VERY much makes it sound like they're ready to toss 2048's on the main grid.