Uploading J2C textures causes downscaling and compression or even fails to upload

[Hecklezz]

Test plan

1. Uploading .j2c files does not work at all on Mac
2. On Windows, use Build menu > Upload > Bulk... to upload the 2 files in J2C test images.zip
3. Verify the uploaded images' dimensions are 512x512 for the smaller image and 2048x2048 for the larger image.
4. There is no support for uploading these images via Build > Upload > Image because that file interface has a filter for tga, bmp, jpg, jpeg, png formats only.
5. There is no support for uploading these images as a Local image because that file interface has a filter for tga, bmp, jpg, jpeg, png formats only.

Environment

Second Life Release 7.1.12.13550888671 (64bit)

Rest of environment-

Release Notes

CPU: Intel(R) Core(TM) i7-9700K CPU @ 3.60GHz (3600 MHz)
Memory: 16302 MB
OS Version: Microsoft Windows 10 64-bit (Build 19045.5608)
Graphics Card Vendor: NVIDIA Corporation
Graphics Card: NVIDIA GeForce RTX 2080/PCIe/SSE2

Windows Graphics Driver Version: 32.0.15.7216
OpenGL Version: 4.6.0 NVIDIA 572.16

Window size: 2220x1250
Font Size Adjustment: 96pt
UI Scaling: 1
Draw distance: 128m
Bandwidth: 3000kbit/s
LOD factor: 1.375
Render quality: 3
Texture memory: 8192MB
Disk cache: Max size 1638.4 MB (100.0% used)

J2C Decoder Version: KDU v7.10.4
Audio Driver Version: OpenAL, version 1.1 ALSOFT 1.23.1 / OpenAL Community / OpenAL Soft: OpenAL Soft
Dullahan: 1.14.0.202408091639
CEF: 118.4.1+g3dd6078+chromium-118.0.5993.54
Chromium: 118.0.5993.54
LibVLC Version: 3.0.21
Voice Server Version:

March 26 2025 00:42:39

Description

With the change done to LLImageJ2C::calcDataSizeJ2C in this commit- 17f515c

If you attempt to upload a J2C texture using the bulk option, the changes result in the textures becoming downscaled and compressed (not an issue while uploading the same texture as png or tga though).
Funnily enough, the viewer actually warns you if you try and upload a J2C texture as 2048x2048 and if you want to downscale it to 1024x1024, and even if you don't tick the box it will get downscaled anyway to 1024x1024 or even 512x512 depending on the texture. This actually causes a upload failure if you don't have free upload (premium plus) and the error tells you that the expected cost has changed (since the texture is no longer 2048x2048 which has a higher upload cost).

The downscaling and compression occur because LLImageJ2C::calcDiscardLevelBytes that calls LLImageJ2C::calcDataSize, fills mDataSizes[] with values that are much smaller with the new LLImageJ2C::calcDataSizeJ2C code versus the original.
This results in the first if (bytes >= (bytes_needed*LLImage::getReverseByteRangePercent()/100)) { break; } condition not being true, and instead increments the discard_level usually 1 or 2 times before it breaks out.
This discard_level now being greater than 0 causes the J2C decoding to return a downscaled and compressed image. Previously with the old code, discard_level from here was returning 0, also uploading the exact same texture as either a png or tga doesn't set discard_level above 0.

There is an additional problem this commit causes, however it only effects viewers with export functionality. Since that is out of scope of the official SecondLife viewer, all I will mention is that it causes exporting PNG and TGA textures (and not J2C since those don't need decoding) to become downscaled and compressed as well since they call the same functions and sets the discard level above 0.

What should be expected to happen:

1. Uploading J2C files should upload and keep their intended resolution and quality, which the viewer indicates it is doing that, but ends up downscaling and compressing it regardless.
2. Uploading 2048x2048 J2C files without free uploads (premium plus) should not fail and error saying the expect cost changed since it got unexpectedly downscaled.
3. (Unrelated to the SecondLife viewer so technically out of scope, but exporting textures should also keep their intended resolution and quality).

Possible solution:
I already have a PR up on the firestorm viewer to fix the exporting issue by simply setting the discard level back to 0 before it attempts to decode the texture. However I was unable to determine an appropriate place to fix this uploading J2C issue without it impacting unrelated J2C decoding.

If someone can determine an appropriate place to fix this issue, feel free to comment and I can test it and put up a PR.

Video of the issue-
J2C Upload bug.mp4

Reproduction steps

1. Upload a J2C texture using the bulk upload option (I only tested on textures >= 512x512)
2. Check the resolution if it has been downscaled
3. If you tried uploading a 2048x2048 J2C texture without free uploads, check if you received an upload error

[akleshchev]

Since we apparently had j2c as an easter egg, I just went and added it properly to supported extension.

[akleshchev]

Test plan:
Ensure j2c files upload with apropriate resolution both from bulk upload and from individual upload. Ensure they can be added as 'local' in texture picker.