OpenJPEG Quality Issues Redux

Removed large TGA example images and replaced with equally compressed JPEG.

We would prefer uncompressed images to do comparisons. Don't worry about the size

^ reverted

thanks

Gonta, Are you trying to upload these with lossless compression?

Can you give more specifics on this test.. How was the image uploaded to SL? Was it marked as lossless or are both examples compressed j2c ?

These were not uploaded with lossless. The TGA is the compressed jpeg2000 created with SL's "Save Texture As..." (Hence massive filesize)

Patch attached. Values identical to http://jira.secondlife.com/browse/VWR-1475 viewer patch http://jira.secondlife.com/secure/attachment/13226/VWR-1475-ll.patch

Included

if (image->components >= 3)
{
cparameters.tcp_mct = 1;
}

No more wierd colors while images are loading!

Everything's awesomesauce, now!

Yeah, we should be using the same values. Good work

Updated in trunk and included updated openjpeg-libsl.dll binary for 32 bit windows systems.

Are our images of a similar quality to the viewer?

Yeah, they are now. Nasty artifacts are gone, as well as the discoloration seen while loading images created prior to the fix.

This fix caused a side effect in that the alpha layers on the head are not baking properly on Avatars (ie: Eyelashes are solid, with no alpha)

Need to get this issue straightened out before continuing LIBOMV-251, Adding Link

I'm seeing some serious weirdness with uploading TGA images. A TGA with no alpha channel appears to have an alpha channel after being uploaded. The problem is more severe if lossless is turned off. When lossless is turned on, the problem happens, but the amount of transparency is small. When lossless is turned off, I see a huge amount of transparency. Both cases are bad.

It's also strange that if I save the bad TGA to disk using the official SL client, the saved image doesn't have any transparency.

I'll attach a couple of samples: plywood.tga and plywood_uploaded_not_lossless.jpg

Windows XP. Happens in 0.5.0 and r2123 (trunk). Happens in SLImageUpload/GridImageUpload as well as my code (Prim Composer for 3ds Max). I think the problem has been around for at least a couple of months, but I hadn't noticed it before because I was uploading sculptmaps which don't care about transparency and since I was uploading them lossless, the problem wasn't obvious at a glance.

Anyway, I'm very interested to know if anyone else sees this.

TGA no alpha channel

TGA with no alpha channel after being uploaded without lossless. Transparency!

Seems like there's been some activity on this issue lately.

I just finished some testing on trunk (r2178). I tried TGA and PNG, lossless and not, transparency in the image and not, using GridImageUpload.exe. The results were good. All of the images were faithful reproductions with and without alpha.

The only problem is that a 24-bit TGA is still getting an alpha channel added, even though it doesn't have one to begin with. This doesn't affect the way that the image looks at all, but it causes the SL viewer to treat it like a transparent image. For example, if you put the texture on two intersecting prims and move the camera around, you will see the textures fighting for which one should be on top. PNG doesn't seem to have this problem. A non-alpha PNG stays non-alpha when it is uploaded.

So, overall, I'd say that this is a big improvement. If we can eliminate the superfluous alpha layer on 24-bit TGAs, then I think it's perfect. For testing, you can use the plywood.tga that I uploaded previously.

Note: I'm having some unrelated issues with trunk which I reported on the mailing list. Having some problems with prim rezzing. I only mention it to let people know that trunk might not be completely stable ATM.

Do we have any chance of getting this resolved? The fact that uploaded 24 bit TGAs get converted to 32 bit images with an alpha channel is a major irritant.

It means, for example, that a linkset that is uploaded with TGA textures will look completely wacky in SL because all of the textures in the build will be fighting with each other for who should be on top. It's intolerable.

I've started digging in the code and I think I see where it happens, but I'm still a long way from understanding how to fix it.

If you look in LoadTGAClass.LoadTGA(), you'll see that it always creates a Bitmap with System.Drawing.Imaging.PixelFormat.Format32bppPArgb, regardless to whether there is an alpha channel in the source image or not. For comparison, the same image in a PNG file and loaded with System.Drawing.Image.FromFile() is given a PixelFormat of Format24bppRgb.

I've found a workaround.

FreeImage (http://freeimage.sourceforge.net/) has a liberal license and an excellent c# wrapper.

Instead of calling:

image = LoadTGAClass.LoadTGA(imagePath);

I can use FreeImage by calling:

FREE_IMAGE_FORMAT imgFormat = FREE_IMAGE_FORMAT.FIF_UNKNOWN;
image = FreeImage.LoadBitmap(imagePath,FREE_IMAGE_LOAD_FLAGS.DEFAULT, ref imgFormat);

And it creates a Bitmap with PixelFormat.Format24bppRgb like I want.

I haven't thoroughly tested it yet, but it was easy to integrate and is well documented. Looks like a winner.

I've tried to isolate the alpha bug in the openjpeg library. It appears this has gone unnoticed since the viewer uploaded images as lossless. Now that they are irreversible enabled, the alpha bug emerges.

Related discussion:
http://groups.google.com/group/openjpeg/tree/browse_frm/thread/4683bba9660c2779#doc_a5d7e1d610446e2f
http://groups.google.com/group/openjpeg/browse_thread/thread/1cb7807b2053592e

Contact me if you or anybody has found a fix to encode images with alpha (32bit, not 24bit).

My understanding is that this is an OpenJPEG issue and we are waiting on an upstream fix. Setting assignee to null for now. If this is incorrect please update.

Any news on this bug? Do we have to use the recommended workaround with freeimage (s. above)?

Complex textured objects look weird after import because of those conversion and alpha issues in OpenJPEG (running TestClient on Windows7 - 64bit). The problem could become even bigger, as the transfers between grids and the usage of 64bit OS (e.g. Win-7 and Linux) is increasing quite fast.

This problem should deserve a higher priority!

Thanks, glem

I was thinking on a workaround...

Is there any way to use the kakadu library from the viewers (llkdu.dll) for uploading images? Is there some example how tu use it?
Or would I need to buy the code for this library and recompile it?

Glem