Pico Pixel SDK

There is a new feature in Pico Pixel: the ability to send raw images to Pico Pixel from any C++ application.

A small history of where this feature is coming from. As you know, 3D graphics engineering deals with a lot of textures. And often, you need to see what’s in those textures. Especially if they are the result of a rendering pass like your depth buffer, G-buffer… However, seeing what’s in the textures while the program is running is a bit of a challenge. Usually, you have to dump texture data into a file format that can be opened by an image viewer.

I have always found the task of viewing GPU textures to be complicated and unnecessary. What if I could just display the texture on the screen? Just like printf does with text!

All programming languages have the equivalent of C/C++ printf. For instance, every “Hello World!” program uses a print function to output text to a console, a file, a web page…

I thought about what it would take to have an API that works for images, the same way printf works for text. The API would have to be:

  • As easy as using printf.
  • Immediate. You should see your images (somewhere) as soon as the image print function is called.
  • Unobtrusive. It should not alter a program’s flow or dramatically affect its performance.
  • It should rely on technology that is native to any system.

That being said, printf has a few weaknesses that would be unsuitable for the goal of printing images. One in particular is that every time code execution goes over a printf call, text is printed. This is often undesirable. Without any control mechanism, calling printf (for instance, in a loop) ends up flooding the text output outlet. Since images can be large in size, continuously printing them out of a running program could have a dramatic effect on performance.

What if we could tell a program to export raw image data at a moment our choosing. This would be an improvement over the way C/C++ printf works. Images would be exported out of a program when the developer choose to. And the rest of the time, the program would simply run unaffected.

The solution I designed, has 3 parts.

  • Just like C/C++ printf has a command line terminal as default output, I needed an outlet for images and I think Pico Pixel desktop application would be perfect for it. It is fast, simple, supports many pixel formats (DXT, BCn, ETC2…) and file formats such as OpenEXR, HDR, KTX and more.
  • A C/C++ API. Developers call functions of the API to export images out of programs. The API is written in simple C/C++ that any compiler can handle.
  • A communication system between programs and Pico Pixel. In my opinion, network sockets are the ideal candidate. Sockets libraries are everywhere. They work across hardware platforms and OSes. They are very well documented.

The result is Pico Pixel SDK. The SDK is made of a few files (open source) you drop in your build environment. They should compile without much trouble. To use the SDK you instantiate PicoPixelClient object and open a connection to Pico Pixel desktop application. The method you use to send pixel data to Pico Pixel is called PixelPrintf.

The best feature of Pico Pixel SDK is that you have a lot of control over images and the moment they are exported. When images are not exported, your program is unaffected by the presence of the SDK.

I am very excited by this feature. It makes Pico Pixel useful in a graphics developer’s toolset. The idea of sharing images over the network between applications is not a new one. However, for us graphics developers, it opens a lot of possibilities if we take advantage of it easily during development. I believe this is a good feature to have and I hope it will save you time in efforts.

print of glxgears color buffer

Pico Pixel SDK GitHub Repo

64 Bits, OpenEXR, RGBE and Khronos KTX Texture Support in Pico Pixel

It has been more than a month since Pico Pixel 0.4.2. During that time, Pico Pixel was upgraded to 64 bits on Windows.

Pico Pixel now reads and displays OpenEXR (.exr), RGBE (.hdr) and KTX (.ktx) file formats. OpenEXR and RGBE are still a work in progress. Tone mapping isn’t applied to high dynamic range images yet. There is some work required in the interface to allow real time configuration of tone mapping operators.

OpenEXR files are quite open ended. They may have many layers, channels and views. Although Pico Pixel tries to display the most common channels, this isn’t enough to completely view and OpenEXR file. I am working on a solution for this. Essentially, the user should have the option to visualize any view, channel or layer.

On that note, Pico Pixel 0.5.0 is out

Pico Pixel 0.4.2

This is the best release so far of Pico Pixel. The last week I have spend much time polishing the interface and resolving some issues. There are still a few known bugs that I plan to address very shortly.

Also, Pico Pixel is now featured on OpenGL.org. Here is the link.

Texture Type Indicators

Pico Pixel can display 2D, cubemap and volume textures. By default, the faces of a cubemap are simultaneously shown in the view; therefore, a cubemap cannot be mistaken for a 2D or 3D texture. However, by default, nothing tells 2D and 3D texture apart.

Next to the application title, an icon lets you see a texture’s type. There’s an icon indicator for each texture type.

Cubemap texture

2D texture

3D texture

But there’s another indicator! Without deep inspection, it is not possible to know if a texture has mipmap levels or not. That’s why Pico Pixel has another indicator to signal the presence of mip levels in a texture.

2D texture and mipmap

These indicators are a simple way to give you, at first glance, some knowledge about the textures.

Cube maps in Pico Pixel

There are two modes to visualize DDS cube map textures in Pico Pixel. The first one is the “flat” view. In this view the cube map is layout open.

DDS cubemap in flat layout

The second one is a 3D view where the cube map is represented as a closed box, seen from the inside.

Cube map 3D view

By default the cross view is the first one you see. Pressing the Enter key switches between the two modes.

DDS Files And BC7 Textures

Quite a few new things in Pico Pixel. Pico now supports DDS files and many texture formats it carries. It also supports BC7 compressed textures which is a format that is much better than S3TC but takes more time to generate with the CPU. There is a GPU implementation of BC7 compression that greatly improve the compression time.

Although DDS file format is a vestige of Direct Draw, it is the only format that supports, 2D textures, cube maps and volumes. Short of using you own file format, DDS is pretty much the only option. And the texture formats in a DDS file may be passed as is directly to the GPU for processing.

And last, there as been general improvements in memory and management and asynchronous loading of texture files.