mipmapped KTX file displayed incorrectly

[MarkCallow]

A mipmapped 64x64 KTX file with 7 mip levels, each of a different color, is displayed as shown in the attached image. The issues are:

1. The texture info display only ever shows "Mip 0" regardless of where the pointer is.
2. Mip levels 1 and 2 are not displayed.
3. Mip level 5 shows 3 different colors: cyan, yellow and black. The cyan pixel is the correct color. Yellow is the level 1 color. Black does not appear anywhere in the texture.

[jaytaoko]

I am assuming you are using texture rgb-mipmap-reference.ktx which is available in the KTX SDK at http://www.khronos.org/opengles/sdk/tools/KTX/

Let me know if that is not the case.

1. I verified. This is a bug in Pico Pixel. Pixels components values are not changing from mip to mip although the color in the mips is changing.
2. I can see Mip level 1 and 2 correctly. I am using Use Pico Pixel 0.6.1 . Use "Shift+Up" and "Shift+Down" to navigate the mips. Can you confirm you are having this issue?
3. I have used Mali Compression Tool as a reference to build the loader in Pico Pixel. This is what it gives for the texture (rgb-mipmap-reference.ktx)

Perceptually, Pico Pixel display the same result as the Mali tool from mip 0 to mip 5 (Once the display of pixel value in Pico Pixel is fixed I will compare the values with the ones in Mali's tool).

The last mip map is where Pico and Mali's tool disagree. From my investigation, I came to the conclusion that Mali's tool is wrong on the last mip level and that the correct color should be pink. Also in mip 6, the black color in Mali's tool is (4, 0, 0, 255). Which is weird.

I am making another pass on the algorithm to see if Pico Pixel is right on the last mip.

[MarkCallow]

I am using 0.6.1.

The default display, whose image I posted, seems like it is intended to show the mip levels stacked up. Clearly levels 1 and 2 are not shown in this display. That is what my #2 was referring to.

I had failed to discover Shift+Up and Shift+Down. Now that you have pointed it out I find I am getting the following totally incorrect displays starting from level 1 and moving up:

Regarding the file, yes I am using the mipmap reference file in the KTX source. Level 5 is supposed to be cyan and level 6 magenta. Those are the colors of the images I input to toktx when I created the file. I will have to investigate the resulting file and toktx more closely.

[jaytaoko]

I failed to understand the nature of the original image you posted. Pico Pixel does not show the mips in a stacked fashion (at least not now). So this image is the result of something wrong happening. And the individual mips you just posted confirm that.

What system are you running (windows 7 or 8) and what is your video card/driver? I need to reproduce this problem.

[MarkCallow]

I am running on 64-bit Windows 7 with a Radeon HD 6750M. The driver supports OpenGL 4.2, I am unable to update the driver as this is a MacBook Pro and the driver is locked.

[jaytaoko]

Your system's specs shouldn't be an issue.

I just created a new visualization mode for 2D textures with mipmaps. I am stacking the mipmaps one on top the other. Not unlike the first image that was submitted for this issue.

All the mip level are showing correctly. I am running Windows 7, 64 bits with a Geforce 570. I will test on system with a Radeon.

[MarkCallow]

That looks better but level 5 is incorrect. I have examined rgb-mipmap-reference.ktx and the toktx code and determined they are correct. Level 5 is cyan.

I believe the problem is that you are not accounting for the unpack alignment of 4 (equivalent to GL_UNPACK_ALIGNMENT == 4). This means that rows of "groups" must be padded to a multiple of 4 bytes. Levels 5 & 6 in this example (6 and 3 bytes/row respectively) are therefore padded to 8 and 4 bytes/row respectively. Rows in all other levels are already a multiple of 4 bytes.

Since level 6 comes out okay, it looks like you must be resetting your pointer between levels. As it is 1x1 image the pad byte will not be encountered. I suspect the Mali tool is incrementing its pointer going from level 5 to 6 hence it is picking up the wrong bytes for level 6 too.

If the above is the default display for mipmaps, then the first shift+up should take you to level 0 as it may be necessary to see the full unobscured image.

[MarkCallow]

I have reported the Mali tool problem to ARM.

[jaytaoko]

You are right! The code wasn't using the right unpack alignment. Here is the result now.

I have opened a bug for it: #5

Stacking the mips one on top the other won't be the default view mode for textures with mipmaps but you will be able to get to it by pressing "Enter" to cycle between the view modes.

Now, there is still the issue you are having with your Radeon card. I am investigating that one...

[jaytaoko]

I have released version Pico Pixel 0.6.2. It fixes issues #3 and #5. The KTX file rgb-mipmap-reference.ktx is rendered correctly and mipmaps have the right color.

I have tested the following system combinations:

• Geforce570+windows 7 x64
• Radeon HD7770+windows 7 x64
• Intel Ivy Bridge GPU

In all cases the file rgb-mipmap-reference.ktx is rendered correctly. See the stacked mipmaps on the Radeon HD 7770

I haven't had any issue with the Radeon HD7770 and my driver is up to date.

Try version 0.6.2 and see if maybe the alignment solves the problem on your system. The screenshots you captured are nothing close to the expected result. So the issue you are having could be elsewhere.

In any case , let me know the result you get.

[MarkCallow]

I tried 0.6.2. After install, it seemed like the old version was still being run. I had to uninstall and re-install. You need to make sure the installer updates and existing installation and you need a way to get the app. to display its version info. It is probably a good idea to add it to the info that is displayed when the program starts up.

When I load the mipmap ktx file, I see the correct stacked miplevels view as seen above. When I press shift+up see the same bad images as I posted above for levels 1, 2 & 4. Levels 3, 5 & 6 have different bad images. That for level 5 shows the checkerboard patter characteristic of fetching the data with an incorrect alignment.

After shift+space, when the new level is displayed, the colour swatch in the lower left corner does not change. However as soon as I move the pointer, the swatch changes to the correct colour for the level. So it looks like you have different code fetching pixel values for the swatch and displaying the texture image.

I have a few other bugs and enhancement requests I'll file separately.

[MarkCallow]

Since PP displays all the miplevels at the size of the base level (64x64 in this case) I would guess that the bug lies in the code for zooming a level to the base level size.

Also when I press "Enter" I get a stacked miplevel display but each of the non-base levels is a smaller version of the incorrect image corresponding to that level that was displayed when cycling through with shift+up.

[MarkCallow]

Hmm! I am getting different results each time I load the file. Most times levels 1, 2 or 3 or all of them are not displayed in stacked mipmap view.

[jaytaoko]

you need a way to get the app. to display its version info. It is probably a good idea to add it to the info that is displayed when the program starts up.

The version number is display in the interface when you start the program or when no image loaded. The text color is faint but the info is there. See this image:

You should see that you have version 0.6.2

When I load the mipmap ktx file, I see the correct stacked miplevels view as seen above. When I press shift+up see the same bad images as I posted above for levels 1, 2 & 4. Levels 3, 5 & 6 have different bad images. That for level 5 shows the checkerboard patter characteristic of fetching the data with an incorrect alignment.

When you first load the image, you should not see the the mips stacked one on top of the other. You should only see the first mip (red). In this mode, Shift+Up and Ship+Down let you navigate through the mips levels.

When you press Enter then you get into the mode where mips stacked are stacked one on top the other like this:

In this mode Shift+Up and Ship+Down have no effect.

(The change of view modes will be made more obvious in a future version)

I have tested rgb-mipmap-reference.ktx in Pico on a system with an Intel GPU (core i3 3220) and one with Radeon HD7770 (on windows 7 and Windows 8) and it shows up fine. No problem on my development system either (with a Geforce 570)

I would like to ask you a few things:

1. If you have another system around with native OpenGL 3.0 support (not a MacBook Bootcamp or VM), can you test on that system?
2. Here is a dds file of a texture with mipmaps BumpyLines.dds (RGB8, 64x64, 7 mip levels). Can you try this texture and check if the mip levels are looking like this:

The picture above is a new view mode I added for the sake of debugging this issue. It is not available in 0.6.2 but it will be in the next release.

Thank you!

[MarkCallow]

You should see that you have version 0.6.2

I suggest you change the colours so it is more noticeable. I completely missed the version info display.

When you first load the image, you should not see the the mips stacked one on top of the other. You should only see the first mip (red). In this mode, Shift+Up and Ship+Down let you navigate through the mips levels.

When you press Enter then you get into the mode where mips stacked are stacked one on top the other like this:

I know that is what you intend but what I described is what is actually happening in my case. BTW, the fact that I get somewhat different results each time I run the program suggests an uninitialized variable.

1. If you have another system around with native OpenGL 3.0 support (not a MacBook Bootcamp or VM), can you test on that system?

I have a Windows XP system. Will Pico Pixel run on XP? Please note that Bootcamp is native. It is not a VM. It simply provides Windows drivers for the Mac hardware. The Radeon driver (which comes from ATI) supports up to OpenGL 4.1. As my VM currently only supports OpenGL 2.1 I have not been using it for Pico and cannot use it.

1. Here is a dds file of a texture with mipmaps BumpyLines.dds (RGB8, 64x64, 7 mip levels). Can you try this texture and check if the mip levels are looking like this:

I will try it.

[jaytaoko]

You are right, bootcamp is native. I meant to say to try on a system where you can freely update the GPU drivers to the latest available.

I have a laptop with a core i3 330M and OpenGL 2.1 support. Although Pico Pixel requires OpenGL 3.0, I was able to hack away that limitation and run Pico on the core i3 330M. Again, the same texture is working fine. All the mipmaps are showing correctly.

I don't think Pico runs on Windows XP. At least, I haven't tried it on an XP machine. Let see what you get with the texture BumpyLines.dds. Do you happen to see problems while rendering other textures or is it only with rgb-mipmap-reference.ktx?

I am tracing the code to look for uninitialized variables.

[MarkCallow]

Will Pico Pixel run on XP?

The installer happily installs it but it will not run. I get a message box saying it "is not a valid Win32 application." So I can only test on the MacBook.

[jaytaoko]

Ok, thanks for the report on Windows XP. I have an old Pentium 4 system. I will install windows XP on it and give it a try.

[MarkCallow]

When I open BumpyLines the initial view is the same incorrect stacked mipmaps with levels 1, 2 & 3 missing that I described when I opened this issue.

When I step through the mip levels I see the same rubbish I have described. The first time a file is opened after starting Pico the patterns shown for levels 4, 5 & 6 are remarkably similar regardless of whether the file is BumpyLines or rgb_mipmap_reference.The rubbish changes each time I re-load the file. It is pretty obvious that uninitialized memory is being displayed. I am seeing whatever values happen to be there.

I do not think these problems are caused by OpenGL driver bugs.

[MarkCallow]

The significance of seeing the same patterns in levels 4, 5 & 6 is that the application likely initialized this memory for another purpose (giving the same patterns) and is reusing it during image display without reinitializing it.

[jaytaoko]

Thank you for reporting your findings. I am working on this issue but haven't find anything yet... Tracing the code to see if there is something un-initialized or platform specific. I am also considering the GLSL shader code for the rendering ...

Just for info, since Pico Pixel uses OpenGL for all of its UI rendering:

1. Do you see rendering issues in the UI other than in texture you open?
2. Any issue you see when you open a texture with no mipmap? Like a bmp file for instance.

I am focusing my search on the code for textures with mipmap levels. Please, let me know if the same issue happens to simple 2D textures.

[jaytaoko]

I have been using an old Pentium 4 system with a Radeon 9800 inside on Windows XP. I can't run Pico Pixel fully on it, but I simplified the rendering to have a test case. The system only has support for OpenGL 2.1.

From what I have seen, there is and issue with the rendering engine of Pico Pixel on that system. Not everything is bad, but I do see the same kind of garbage data you have been talking about.

This system is not quite the same as yours but it gives me something to work on. I should be able to fix the rendering issues I am having with my test case. It could be that the cause of these issues are similar to the ones on your system.

[MarkCallow]

Thank you for your investigations.

I see no issues with the UI rendering, only with the texture being displayed.

I don't see any issue when I open a texture with no mipmap. To be thorough I should test with some other texture type where shift + {up,down} will have an effect such as a cubemap or 3D texture. Creating such textures is on my TODO list for libktx. Do you have any you could send me, either .ktx or .dds?

[jaytaoko]

Here is what I found out on my Windows XP system.

First, a few day ago, Pico Pixel didn`t run on Windows XP. It was never attempted. It took some tweeks and adjustment to the build system to allow Pico Pixel's framework to be built on XP. This effort has now been completed. This effort has been completed. Except for one remaining issue, Pico Pixel runs on Windows XP. The remaining issue is that Pico Pixel uses Direct2D for text rendering and Direct2D isn't supported on XP. So text rendering in the UI has to be disable until a replacement for Direct2D is put in place (fallback to GDI+ text rendering).

Now the finding with different video cards.

Radeon 9800: It hardly supports OpenGL 2.1 despite the driver report. I did had issues with that GPU, that I attribute to bugs in the driver. One issue in particular was resulting in wrong rendering (garbage in the rendering window). Once that issue got resolved, I was able to run Pico Pixel and use texture rgb-mipmap-reference.ktx. There was no issue in the rendering. The mipmaps were looking fine.

Geforce 6600: Support OpenGL 2.1 and more. I had no issue with that GPU. Pico Pixel worked fine on it and textures rgb-mipmap-reference.ktx and its mipmaps were rendered correctly.

Radeon HD 3450: Support OpenGL 3.3. Again, no issues with that GPU. Pico Pixel worked fine on it and textures rgb-mipmap-reference.ktx and its mipmaps were rendered correctly.

Even though the Radeon 9800 had issues at first, I doubt they are related to the problem you have on your system. After all, that GPU is from another time and its driver relegated in legacy support.

So I don't think I have been able to reproduce the issue you have. The experience of porting Pico Pixel to windows XP gave the opportunity to spot a few bugs here and there but nothing that I believe could be responsible for the rendering bug on your system. Still, I am preparing a new release with the latest fixes for you to try.

As for the code itself, I haven't found any issue that could cause the problem but I won't jump to a definitive conclusion just yet. That being said, at this stage, I have tried various combinations of OS and GPU systems and I am still looking for a way to reproduce the problem.

Let me release Pico Pixel 0.6.3 and we can see where things are. I will provide you with some textures to test (including some DDS).

Thank you for you patience!

[jaytaoko]

I just released Pico Pixel version 0.6.3. Give it a try and let see what you get.

In case you still have the problem, there is something I would like you to try. For every mip level of texture rgb-mipmap-reference.ktx, take a look at the color swatch and make sure that you have the following values in it:

• mip 0: RGB= (255, 0, 0)
• mip 1: RGB= (255, 102, 0)
• mip 2: RGB= (255, 255, 0)
• mip 3: RGB= (0, 255, 0)
• mip 4: RGB= (0, 0, 255)
• mip 5: RGB= (0, 255, 255)
• mip 6: RGB= (255, 0, 255)

This should help verify if the texture is correctly decoded on the CPU or not.

[MarkCallow]

In case you still have the problem, there is something I would like you to try. For every mip level of texture rgb-mipmap-reference.ktx, take a look at the color swatch and make sure that you have the following values in it:

0.6.3 still has the problem. However the color swatch shows the correct values for all levels, as it did in 0.6.2 as I reported here 10 days ago.

Do you have a cubemap or 3D texture file that I can try?

I'm going to try the AMD PerfStudio to see if I can learn anything from that.

[MarkCallow]

I'm going to try the AMD PerfStudio to see if I can learn anything from that.

No go. Pico Pixel crashes when I try to have GPUPerfStudio run it.

[jaytaoko]

Sorry for the delay! The fact that the color swatch shows the correct value means the texture is correctly decoded on the CPU. The RGB data of the texture is then loaded as an OpenGL texture (GL_RGB).

Here are a few textures to test: DXT1 2D+Mipmap RGB8 2D+Mipmap DXT1 Cubemap+Mipmap

What do you get with those and Pico Pixel 0.6.3? Thanks

[jaytaoko]

No go. Pico Pixel crashes when I try to have GPUPerfStudio run it.

There is indeed a problem that prevents Pico Pixel from running under GPUPerfStudio. The issues has to do with Direct2D when the program starts. I will see if I can have a quick fix for this...

[MarkCallow]

Here are a few textures to test: DXT1 2D+Mipmap

Works

RGB8 2D+Mipmap

Exhibits same problems as rgb-mipmap-reference.ktx

DXT1 Cubemap+Mipmap

Works.

[jaytaoko]

Wow, it is interesting that "RGB8 2D+Mipmap" exhibits the same issue while the DXT1 textures are fine... Surprising but it is a good hint.

Here is another texture to try: BGRA8 2D+Mipmap

In this latest texture, there are 4 component per pixels. This could help me to further isolate the problem. Thank you for your patience!

[jaytaoko]

I have prepared a special build of Pico Pixel to test. I did a few changes and I would like you to try it on your bootcamp machine with the Radeon HD 6750M. Give a try to the texture that have the issue.

The build is a zipped version of Pico Pixel. It does not have an installer. Just unzip the package and run Pico Pixel executable.

Issue#1 Build 0

Thank you!

[MarkCallow]

The test build works with rgb-mipmap-reference.ktx and all the textures you have provided in this issues list. Thank you for your perseverance in the face of not being able to reproduce the problem yourself. What did it finally turn out to be?

For the record, BGRA8 2D+Mipmap on 0.6.3 exhibited the same problems as rgb-mipmap-reference.ktx.

[jaytaoko]

Very happy to hear that! And I know what fixed it!

When Pico Pixel graphics framework creates an OpenGL texture, it first call glTexImage2D to define the texture (width, height, internal format...) and later, glTexSubImage2D to fill the entire texture with valid data.

In the graphics framework, the call to glTexImage2D, takes a null pointer as the last parameter and this is fine since the texture isn't being used until it is filled with a call to glTexSubImage2D.

(Note that the code is not using pixel buffer objects to load data in the texture)

However, there was a time when a valid pointer of random data was being allocated and fed into glTexImage2D so that the texture was defined with real data, even if that data was to be replaced with a call to glTexSubImage2D and the real texture data. And I remember it was necessary to do that because otherwise, the texture wouldn't show up correctly on an AMD GPU/driver combo.

Yet, a year ago or so, the drivers had improved so that it wasn't necessary to provide glTexImage2D with random data. So, glTexImage2D is called with null as the last parameter. As I have tested on many systems and GPU/drivers, this worked fine except in your situation.

The test I had you performed have eliminated the possibility of decoding errors on the CPU. What remained was how the texture was loaded into the OpenGL. And I remembered why, in the code, glTexImage2D used to be call with a valid pointer as the last parameter.

It could be that the code didn't follow the OpenGL spec to the letter and yet the drivers I tried were overlooking the transgression. Or maybe the code is correct and if you can't update the drivers on your system, then you are left with the issues you have seen.

Anyways, the solution for me is to fix this issue by calling glTexImage2D with a valid pointer. I am preparing a new release (0.6.4) with this fix. It will be out very soon.

Thank you for your patience and feedback on this issue. I will let you know as soon as the fix is released.

[jaytaoko]

I have released Pico Pixel 0.6.4. Give it a try! If all is fine then I will close this issue! Thank you very much for your feedback!

[MarkCallow]

I tried 0.6.4. It works.

Sorry to say but your work may have been wasted. I updated BootCamp from v3.3 to v5.0. As part of that update, the AMD drivers were updated from Catalyst 8.812.0.0 (2011.4.1 - yes April Fools' day) OpenGL 4.1 to 9.2.0.0 (2012.9.27) OpenGL 4.2 and 0.6.3 works fine with this driver.

However the very first application I ran on this driver revealed 2 new bugs: a line loop which is supposed to draw a rectangular frame around the viewport is drawing a diagonal cross and texture filtering is gathering texels from the bottom row(s?) of the texture and displaying them on the top.

I am sorry I did not attempt to update bootcamp before. Apple makes it difficult. The updates do not appear in Apple Software Update on Windows or in the BootCamp system tray item and there is no link to the BootCamp support site. I eventually had BootCamp Assistant copy the drivers to a USB stick, even though I had no idea if they were newer than the ones I had.

[jaytaoko]

Glad to hear that it works. No worry, this wasn't a waste of time at all! There are many systems similar to yours out there and since upgrading Bootcamp isn't obvious or easy, they are bound to have the same issue that you had. With 0.6.4, that won't happen fortunately...

In the process, Pico Pixel gained a partial port to Windows XP which may be completed later.

Please, submit bugs for the new problems you have encountered (filtering issue and rectangle loop) and I will address them. Thanks!

[MarkCallow]

Please, submit bugs for the new problems you have encountered (filtering issue and rectangle loop) and I will address them. Thanks!

I observed those new bugs while running my own application. But if I see any more in PicoPixel I'll be sure to submit them.