Jump to content

Getting OpenJPEG 2+ to work?


Recommended Posts

I've been fiddling with compiling the official viewer, and it seems OpenJPEG 1.5 is broken in the latest build. I've looked around and found Kitty Barnett's patch in Catznip for v2.3, which sorta works, but I've noticed when textures aren't fully loaded, they appear corrupted looking.

image.thumb.png.40794f75947d312123707305e8908020.png

I've noticed that Firestorm is using v2.4 for OS builds, and I can't figure out what they did to make it fully work.

Any help on this would be appreciated.

Link to comment
Share on other sites

OpenJPEG v1.5 and newer got totally crippled for SL usage purposes. The JPEG2000 level of details plain does not work with those versions (they can only decode textures successfully at full LOD), and JPEG2000 encoding is also bogus with them.

That's why I kept OpenJPEG v1.4.0.635, fixed/improved with many patches, either backported from newer versions for security fixes, or created by me (and recently from Kathrine Jansma  for an AVX2 optimization) for the Cool VL Viewer (the patched version has been made part of my viewer sources for these reasons)...

However, please be aware that the ”rainbow textures” you are experiencing may also be the result of bugs in libcurl's HTTP pipelining code (the only 100% working and safe version of libcurl with regard to pipelining is v7.47 with LL's patches, as used by default in my viewer)...

Edited by Henri Beauchamp
  • Like 2
Link to comment
Share on other sites

8 hours ago, Henri Beauchamp said:

OpenJPEG v1.5 and newer got totally crippled for SL usage purposes. The JPEG2000 level of details plain does not work with those versions (they can only decode textures successfully at full LOD), and JPEG2000 encoding is also bogus with them.

That's why I kept OpenJPEG v1.4.0.635, fixed/improved with many patches, either backported from newer versions for security fixes, or created by me (and recently from Kathrine Jansma  for an AVX2 optimization) for the Cool VL Viewer (the patched version has been made part of my viewer sources for these reasons)...

However, please be aware that the ”rainbow textures” you are experiencing may also be the result of bugs in libcurl's HTTP pipelining code (the only 100% working and safe version of libcurl with regard to pipelining is v7.47 with LL's patches, as used by default in my viewer)...

Mind if I snag your version of it?

Link to comment
Share on other sites

Not sure what OpenJPEG version or package you used, but 1.5 and the newer 2.x versions until now don't support partial decodes, hence textures will be broken. There is a years-old pull request on the OpenJPEG repository to add partial decode support, so if you try to build an OpenJPEG package yourself, you will have to include the changes from the pull request.

  • Like 1
Link to comment
Share on other sites

  • 2 years later...
Posted (edited)
3 hours ago, mygoditsfullofstars said:

OpenJPEG 1.4 is a fossil............

 

Yo, man, fossils have stability.

Edited by Ardy Lay
Link to comment
Share on other sites

6 hours ago, mygoditsfullofstars said:

OpenJPEG 1.4 is a fossil............

It's not quite v1.4 any more (it got optimized with SSE/AVX and NEON for ARM, and manual micro-optimizations) and got all the known bugs fixed.

And... It happens to work way better than v2.5: I did try and update to the latter, but it did not work well with, for example, an ugly way to rez loading textures, when compared with v1.4, and texture decoding failures I do not have with v1.4...

If it ain't broke, don't fix it  ! 😛

Link to comment
Share on other sites

Posted (edited)

Do you have a link to the repo please, Henri? I'd like to give your optimised not-quite-v1.4 go if I could please!

I reached out to Kakadu just for a giggle, just to enquire how much a personal non-commercial no-distribution licence might be (they don't list prices - they like to quote you), and they got back to me and asked if US$250 per year would be "within [my] financial capacity" and I politely replied that I would leave it and continue with OpenJPEG. 😃

 

 

Edited by Rebecca Ashbourne
Link to comment
Share on other sites

2 hours ago, Rebecca Ashbourne said:

Do you have a link to the repo please, Henri?

The modified OpenJPEG v1.4.0.635 library sources are integrated with the Cool VL Viewer sources (in the linden/indra/libopenjpeg/ directory).

My viewer sources and the sources and binaries for the third party libraries it uses are available from this page.

Link to comment
Share on other sites

Long term, the way forward is to try and get LL to fix their OpenJPEG2 implementation (or submit a PR to them if you are in a position to fix it yourself).

OpenJPEG2 had a massive amount of work done to it by its developers a few years ago to improve its performance. I don't have the link handy, but I remember seeing benchmarks of OpenJPEG2 vs OpenJPEG 1.x and the performance of OpenJPEG2 was substantially better.

While OpenJPEG 1.4 apparently "just works" in some viewers, there's no future in it - its been end of life a long time.

Not to mention the risks... https://www.cvedetails.com/version/451894/Uclouvain-Openjpeg-1.4.html

 

Link to comment
Share on other sites

Posted (edited)
On 7/5/2024 at 5:17 AM, mygoditsfullofstars said:

OpenJPEG2 had a massive amount of work done to it by its developers a few years ago to improve its performance.

Part of that work was backported to OpenJPEG v1.4 by me. I myself implemented more optimizations, and Kathrine Jansma also contributed a couple AVX optimizations to v1.4...

It performs quite well !

On 7/5/2024 at 5:17 AM, mygoditsfullofstars said:

I did plug/fix all known CVEs in my version of the OpenJPEG v1.4 library (not utilities, which we do not use and therefore do not care about).

But since these fixes have been implemented a while ago, I will re-scan that list to see if new CVEs need addressing (I had a quick look at one such high-risk new CVE, but it impacts a utility, not the the library itself).

Edited by Henri Beauchamp
Link to comment
Share on other sites

Just chiming in. After merging PBR i got set back to whatever LL used (2.x, something something). It does feature partial decode now (kinda) but its really buggy and causes partially decoded textures to look awkward, of course they are only in transition but its still something that a lot of people have been seeing and was more than just a minor visual temporary inconvenience, it pulled so much attention that i ripped out the entire partial decode support and went back to my trusty OpenJpeg 1.4 that was working fine.

I'm convinced OpenJpeg is a dead horse that we've been riding for way too many years, completely neglected by LL because they don't use it and completely neglected by pretty much everyone else too because we either keep using old versions or avoiding OpenJpeg alltogether like LL does. LL should really be forced to use their own unfunctional trash sometime, have them only use OpenJpeg just for them to see all the things that are broken with it and actually get it fixed.

  • Like 1
Link to comment
Share on other sites

5 hours ago, NiranV Dean said:

After merging PBR i got set back to whatever LL used (2.x, something something). It does feature partial decode now (kinda) but its really buggy and causes partially decoded textures to look awkward, of course they are only in transition but its still something that a lot of people have been seeing and was more than just a minor visual temporary inconvenience, it pulled so much attention that i ripped out the entire partial decode support and went back to my trusty OpenJpeg 1.4 that was working fine.

Exactly the same experience (with OpenJPEG v2.5) for me... And it was not even the first time I tried to use OpenJPEG 2 (IIRC, I also tried with v2.2 and 2.4 in the past, to no avail).

Link to comment
Share on other sites

4 hours ago, Monty Linden said:

LOL !  Reading that challenge:

Quote

Your task in this problem is to build on the OpenJPEG library, improving its decode speed.

Well, I have been doing it, for years, and for free !

All you have to do, guys, is to reuse the sources in my viewer sources tree... 😛

Link to comment
Share on other sites

Since you are here Henri. 

I have some novice questions.

Jpeg2000 is ancient, on the web we are at things like webp.

Also texture downloading, I think at one point weren't they stored on sim server?

Seems to me they could upgrade these jpeg2000 on the fly something like cloud front does for the web, and are they compressed?

They have asset servers now so we are downloading from there but still slow. Would the addition of more asset servers help? Download from more locations?

Link to comment
Share on other sites

Posted (edited)
1 hour ago, Jase Devin said:

Jpeg2000 is ancient, on the web we are at things like webp.

WebP does not support LODs, i.e. you cannot decode the image at various levels of detail as you read more of the encoded file, like JPEG2000 allows.

1 hour ago, Jase Devin said:

Seems to me they could upgrade these jpeg2000 on the fly something like cloud front does for the web, and are they compressed?

Images are served as they are stored. Doing an ”on the fly” conversion would be incredibly costly in delay and server CPU usage.

1 hour ago, Jase Devin said:

They have asset servers now so we are downloading from there but still slow. Would the addition of more asset servers help? Download from more locations?

SL is using CDN servers to deliver textures and assets data: they already are proxy servers close to your home location, on the condition you use a DNS server physically located in your country, since you will be served by a CDN server close to the DNS.

Edited by Henri Beauchamp
  • Thanks 2
Link to comment
Share on other sites

Frankly I'd be happy if someone could just fix it so we get fuzzy / pixillated pics for partial decodes rather than the Andy Warhol rainbow effect that I showed in the pic I posted a few days ago. That would probably be "good enough" for me. 

 

Link to comment
Share on other sites

Posted (edited)
22 hours ago, Henri Beauchamp said:

Exactly the same experience (with OpenJPEG v2.5) for me... And it was not even the first time I tried to use OpenJPEG 2 (IIRC, I also tried with v2.2 and 2.4 in the past, to no avail).

Looks lile OpenJPEG v2.5.2 does have support for partial decodes now. Basically the PR that @Ansariel Hiller mentioned back in January 2022 got merged to master. But as @NiranV Dean says, it doesn't seem to resolve the issue, as evidenced by my test builds of LL Official and Firestorm. 

One suggestion I've had from someone is to use OpenJPEG 2.5 and make sure strict mode disabled, via a call to opj_decoder_set_strict_mode()

I will give that a go as, although I've managed to get my private build of Firestorm to build successfully with Niram's OpenJPEG 1.5 (it was a stepping-stone towards Henri's custom 1.4+), I would prefer to get 2.5 working though. 

Update: Ok, forget that. The latest Firestorm version of llimagej2coj.cpp is already calling opj_decoder_set_strict_mode(decoder, OPJ_FALSE)

 

Edited by Rebecca Ashbourne
Link to comment
Share on other sites

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
 Share

×
×
  • Create New...