Details

    • Type: Bug Bug
    • Status: Reopened Reopened
    • Priority: Major Major
    • Resolution: Unresolved
    • Affects Version/s: 0.4.0, 0.4.1, 0.4.1.1, 0.6.1.1
    • Fix Version/s: None
    • Component/s: None
    • Labels:
      None
    • Severity:
      High
    • Environment:
      .NET / Windows32
    • Steps to Reproduce:
      Hide

      Upload a smaller ( < 1024x1024) detailed image with SLImageUpload. To more easily see artifacts use contrasting, monochromatic hues.

      Show
      Upload a smaller ( < 1024x1024) detailed image with SLImageUpload. To more easily see artifacts use contrasting, monochromatic hues.

      Description

      Nasty artifacts and poor image quality present on images encoded and uploaded via openJPEG-libsl.

      1. LIBOMV-243.patch
        0.7 kB
        gonta maltz
      2. LIBOMV-243-with_image_component_sensitivity.patch
        0.8 kB
        gonta maltz
      3. openjpeg_result.tga
        768 kB
        gonta maltz
      4. plywood.tga
        768 kB
        Shack Dougall
      5. SL_result.tga
        768 kB
        gonta maltz
      1. original_image.png
        139 kB
      2. plywood_uploaded_not_lossless.jpg
        104 kB

        Issue Links

          Activity

          gonta maltz made changes -
          Field Original Value New Value
          Attachment openjpeg_result.tga [ 10140 ]
          gonta maltz made changes -
          Attachment SL_result.tga [ 10141 ]
          Hide
          gonta maltz added a comment -

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

          Show
          gonta maltz added a comment - Removed large TGA example images and replaced with equally compressed JPEG.
          gonta maltz made changes -
          Attachment openjpeg_result.jpg [ 10143 ]
          gonta maltz made changes -
          Attachment SL_result.jpg [ 10144 ]
          gonta maltz made changes -
          Comment [ Removed large TGA example images and replaced with equally compressed JPEG. ]
          Hide
          James Neal added a comment -

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

          Show
          James Neal added a comment - We would prefer uncompressed images to do comparisons. Don't worry about the size
          gonta maltz made changes -
          Affects Version/s 0.4.1.1 [ 10012 ]
          Affects Version/s 0.4.1 [ 10011 ]
          Affects Version/s 0.4.0 [ 10010 ]
          Affects Version/s 0.4.x [ 10009 ]
          gonta maltz made changes -
          Attachment SL_result.jpg [ 10144 ]
          gonta maltz made changes -
          Attachment openjpeg_result.jpg [ 10143 ]
          Hide
          gonta maltz added a comment -

          ^ reverted

          Show
          gonta maltz added a comment - ^ reverted
          gonta maltz made changes -
          Attachment SL_result.tga [ 10145 ]
          Attachment openjpeg_result.tga [ 10146 ]
          Hide
          James Neal added a comment -

          thanks

          Show
          James Neal added a comment - thanks
          Hide
          Jim Radford added a comment -

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

          Show
          Jim Radford added a comment - Gonta, Are you trying to upload these with lossless compression?
          Hide
          James Neal added a comment -

          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 ?

          Show
          James Neal added a comment - 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 ?
          Hide
          gonta maltz added a comment - - edited

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

          Show
          gonta maltz added a comment - - edited These were not uploaded with lossless. The TGA is the compressed jpeg2000 created with SL's "Save Texture As..." (Hence massive filesize)
          Hide
          gonta maltz added a comment -
          Show
          gonta maltz added a comment - 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
          gonta maltz made changes -
          Attachment LIBOMV-243.patch [ 10148 ]
          Hide
          gonta maltz added a comment -

          Included

          if (image->components >= 3)

          { cparameters.tcp_mct = 1; }

          No more wierd colors while images are loading!

          Show
          gonta maltz added a comment - Included if (image->components >= 3) { cparameters.tcp_mct = 1; } No more wierd colors while images are loading!
          gonta maltz made changes -
          Hide
          Uchi Desmoulins added a comment -

          Everything's awesomesauce, now!

          Show
          Uchi Desmoulins added a comment - Everything's awesomesauce, now!
          Hide
          James Neal added a comment -

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

          Show
          James Neal added a comment - Yeah, we should be using the same values. Good work
          James Neal made changes -
          Assignee Jim Radford [ jradford ]
          Jim Radford made changes -
          Status Open [ 1 ] In Progress [ 3 ]
          Hide
          Jim Radford added a comment -

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

          Show
          Jim Radford added a comment - Updated in trunk and included updated openjpeg-libsl.dll binary for 32 bit windows systems.
          Jim Radford made changes -
          Status In Progress [ 3 ] Resolved [ 5 ]
          Fix Version/s 0.5.0 [ 10013 ]
          Resolution Fixed [ 1 ]
          Jim Radford made changes -
          Status Resolved [ 5 ] Closed [ 6 ]
          Jim Radford made changes -
          Link This issue is blocked by LIBOMV-251 [ LIBOMV-251 ]
          View full commit
          LIBOMV-243 * Corrects improper openjpeg parameters which caused artifacts in some smaller images Thanks Gonta for the patch * Updates 32 bit openjpeg-libsl.dll binary git-svn-id: http://libopenmetaverse.googlecode.com/svn/trunk@1882 52acb1d6-8a22-11de-b505-999d5b087335
          Hide
          James Neal added a comment - - edited

          Are our images of a similar quality to the viewer?

          Show
          James Neal added a comment - - edited Are our images of a similar quality to the viewer?
          James Neal made changes -
          Workflow jira [ 10311 ] Beta workflow [ 10565 ]
          Hide
          gonta maltz added a comment -

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

          Show
          gonta maltz added a comment - Yeah, they are now. Nasty artifacts are gone, as well as the discoloration seen while loading images created prior to the fix.
          Hide
          Jim Radford added a comment -

          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)

          Show
          Jim Radford added a comment - 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)
          Jim Radford made changes -
          Resolution Fixed [ 1 ]
          Status Closed [ 6 ] Reopened [ 4 ]
          Hide
          Jim Radford added a comment -

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

          Show
          Jim Radford added a comment - Need to get this issue straightened out before continuing LIBOMV-251 , Adding Link
          Jim Radford made changes -
          Link This issue blocks LIBOMV-251 [ LIBOMV-251 ]
          James Neal made changes -
          Fix Version/s 0.5.1 [ 10030 ]
          Fix Version/s 0.5.0 [ 10013 ]
          Hide
          Shack Dougall added a comment -

          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.

          Show
          Shack Dougall added a comment - 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.
          Hide
          Shack Dougall added a comment -

          TGA no alpha channel

          Show
          Shack Dougall added a comment - TGA no alpha channel
          Shack Dougall made changes -
          Attachment plywood.tga [ 10225 ]
          Hide
          Shack Dougall added a comment -

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

          Show
          Shack Dougall added a comment - TGA with no alpha channel after being uploaded without lossless. Transparency!
          Shack Dougall made changes -
          Attachment plywood_uploaded_not_lossless.jpg [ 10226 ]
          Hide
          Shack Dougall added a comment -

          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.

          Show
          Shack Dougall added a comment - 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.
          John Hurliman made changes -
          Assignee Jim Radford [ jradford ] John Hurliman [ jhurliman ]
          Hide
          Shack Dougall added a comment -

          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.

          Show
          Shack Dougall added a comment - 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.
          Hide
          Shack Dougall added a comment -

          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.

          Show
          Shack Dougall added a comment - 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.
          James Neal made changes -
          Fix Version/s 0.6.2 [ 10081 ]
          Fix Version/s 0.6.1 [ 10070 ]
          Jim Radford made changes -
          Affects Version/s 0.6.1.1 [ 10080 ]
          Affects Version/s 0.5.0 [ 10013 ]
          Fix Version/s 0.6.3 [ 10091 ]
          Fix Version/s 0.6.2 [ 10081 ]
          Hide
          Jonathan Ballard added a comment - - edited

          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).

          Show
          Jonathan Ballard added a comment - - edited 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).
          Hide
          John Hurliman added a comment -

          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.

          Show
          John Hurliman added a comment - 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.
          John Hurliman made changes -
          Assignee John Hurliman [ jhurliman ]
          Jim Radford made changes -
          Fix Version/s 1.0 (Future) [ 10092 ]
          Fix Version/s 0.6.3 [ 10091 ]
          Hide
          glem02 added a comment - - edited

          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

          Show
          glem02 added a comment - - edited 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
          glem02 made changes -
          Priority Minor [ 4 ] Major [ 3 ]
          Severity High
          Hide
          glem02 added a comment -

          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

          Show
          glem02 added a comment - 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
          Latif Khalifa made changes -
          Fix Version/s 1.0 (Future) [ 10092 ]

            People

            • Assignee:
              Unassigned
              Reporter:
              gonta maltz
            • Votes:
              3 Vote for this issue
              Watchers:
              4 Start watching this issue

              Dates

              • Created:
                Updated: