search

cinderblocks / libremetaverse

An fork of the libopenmetaverse library striving for performance improvements and up-to-date compatibility with SL/OS/Halcyon
BSD 3-Clause "New" or "Revised" License
60 stars 40 forks source link

Looking for Ray and a proper OpenJPeg #56

Closed mdickson closed 2 years ago

mdickson commented 2 years ago

Sorry for this mechanism to address a question. I don't have a way afaik to contact you otherwise. I'm in the process of updating a Halcyon derived codebase to use the latest LibreMetaverse. From the legacy version in use now an obvious change was the factoring of OpenJPEG out of the codebase into what I think is a separate OpenJPEG library (named -LMV). Is this a correct version to use?

The other issue is a missing Class in .Types). The Halcyon code was using Ray defined there. Did this move or get renamed? If not, I can dig up the source in an older tree and migrate it to Halcyon directly. Probably the more correct thing to do if the Ray class isn't used in LibreMetaverse directly.

Finally what is the best way to follow up on questions like this? I can enter issues and I don't expect a ton of this sort of question but I'm happy to use a different mechanism if opening issues feels wrong.

cinderblocks commented 2 years ago

This is the perfect place for these questions. As eventually, I would like to write a migration guide that answers a lot of these type of questions.

JPEG2000 support was completely rewritten and is contained in a seperate library: https://github.com/cinderblocks/OpenJpegDotNet under the develop branch. Building it can be a little tricky, but the results are worth it for OpenJPEG 2.x. It can also be found on NuGet: https://www.nuget.org/packages/OpenJpegDotNet-LMV/ Note that the API is subject to change as well as the library name as it matures further from its roots.

I just readded the Ray class on HEAD. There may be others who use it too. (It's a very simple struct.)

mdickson commented 2 years ago

Ok I have the Ray class now and thats resolved. One more apparent API issue. There is a Delegate interface used when doing decoding on jpegs that is using a J2KLayerInfo symbol. I've added and converted to use the OpenJPEG library using the NuGet package. I can try and download and compile it but I suspect the semantics of this decoding pipeline have just changed. The Symbol was part of the CSJ2K module. Do I need to pick that up somewhere and build it or is there a different symbol to use? I am going to dig into this deeper and I've just done a cursory look for now. Any pointers are appreciated.

cinderblocks commented 2 years ago

What are you trying to do with that struct? J2KLayerInfo was hackishly accessing unmanaged memory, and very poorly at that. If OpenJpegDotNet isn't able to fit the need, perhaps it can be further developed to fill the role.

mdickson commented 2 years ago

Its used in the texture decoding pipeline in Halcyon. I'll need to look at a rewrite clearly for the reasons you mentioned. Let mw did into the code a bit and see how to replace the usage.

cinderblocks commented 2 years ago

In OpenJpegDotNet, the primary object you wind up working with is OpenJpegDotNet.Image. From there, anything you would probably need out of J2KLayerInfo would be available in its Components property. OpenJpegDotNet matches up much more closely to the JP2000 specification and OpenJPEG's implementation thereof instead of reinventing the wheel and hiding the guts behind magic.

In the future, I will probably be doing away with ManagedImage as well. Right now it's all slopped together because I was not ready to dive into rewriting Baking.

cinderblocks commented 2 years ago

I am closing this and directing questions of this nature to the newly created https://github.com/cinderblocks/libremetaverse/discussions