Entries for tag "graphics", ordered from most recent. Entry count: 50.
# 3 Rules to Make You Image Looking Good on a Projector
As I go to conferences (and sometimes present my slides), do music visualizations on parties and attend demoscene parties, I started noticing what looks good and what doesn't when presented on a big screen using a projector. It's often not the same thing as you expect when preparing your content and see it on a monitor. The problem is that while monitors usually do pretty good job in representing all shades of colors and brightnesses and we adjust them to see the image from the right distance and in good lighting conditions, with image presented from a projector it's often not the case. You never know what to expect from the quality of the image before you actually enter the venue where you are going to present. That's why I have prepared three simple rules to follow if you want your content to look good on a projector:
1. Use High Contrast
White (or almost white) objects on black background are OK. Black (or almost black) objects on white background are also OK. Gray objects on gray background are not OK. In other words: don't rely on subtle differences in brightness.
Why? Because they may not be visible on the big screen. Sometimes the projector is not powerful enough to ensure sufficient contrast and so everything looks very dark. Sometimes the lighting conditions are such that everything looks very bright. Sometimes the gamma of the image is very different than you experience when preparing your content. (By gamma, I basically mean the curve showing how perceived brightness depends on the brightness value of a pixel.) As a result, all the dark colors may be indistinguishable and completely black, or all the bright colors may be indistinguishable and completely white, or conversely - small difference in pixel brightness can make large difference on the big screen.
So basically use high contrast for all your images. Using subtle differences in pixel brightness for adding some details is OK, but make sure the image looks good and conveys all the key information also without them, relying only on the difference between black and white.
2. Don't Rely on Colors
Monitors can represent most of the colors from sRGB space more or less correctly, but you shouldn't expect the same from a projector. Some colors may seem brighter or darker than expected. Sometimes colors just look completely different on the big screen.
That's why you shouldn't rely on them. Showing some details using colors is OK, but make sure your image looks good and conveys all the key information also without them, relying on brightness alone.
I can remember watching a business presentation where some data was shown on a graph using a yellow line on white background. It was completely invisible on the big screen, so the presenter turned his laptop for us so we could see it. Another time I needed to present on a screen that was lit by a blue lamp and there was no way to turn it off. All parts of the image looked more or less blue and there was no point in using any colors. I even seen a situation where one of RGB components didn't work at all because of the broken cable!
3. Use Big Objects
Use only large font size, prefer big objects of uniform brightness/color and make all lines thick. Don't show any important things as small objects or characters and don't use single-pixel width lines.
Why? Because they may not be readable or visible at all. Sometimes the screen is too small or some viewers sit too far from it. Some people have bad vision and might forget their glasses. Sometimes the image gets downscaled. Many projectors have low resolution. The image quality may just be bad - for example long VGA (D-sub) cable introduces some horizontal blur. I sometimes connect my laptop to a HDMI video switcher that presents itself to the laptop as Full HD (1080p) display, while its output is actually connected to a projector having native resolution of 1024 x 768. I once needed to present on an old projector that didn't have either D-sub or HDMI input, only Composite, S-Video and... a DVD player. Not only I needed a special converter, but also image quality was very bad because standard definition PAL TV signal is only 576i.
For good examples, see demos from Cocoon group (see the group on pouet.net, search YouTube). I think they are not only masterpiece of both technology and art, but they are also deliberately prepared to look great on a big screen by following the rules similar to what I described here.
# Color Temperature of Your Lighting
In photography, video and all graphics in general there are so much more parameters to consider than just exposure, meaning lighter or darker image. One of them is color temperature, or white balance. It's about what we consider "white" - a frame of reference, especially concerning light source and so all the objects lit by it. It's not real temperature, but we measure it in Kelvins. Paradoxically, lower color temperature values (like 3000K) mean colors that we call "warmer" - more towards yellow, orange or red. Higher temeratures (like 7000K) mean "cooler" colors - more towards blue. Values like 6500K are considered equivalent of a sunlight during the day, while light bulbs usually have around 3000K. Color temperature of your lighting is important when you work with colors on a computer. They recommend to use 6500K light source for that purpose.
I decided to make an experiment. Below you can see photos of part of my room, with a test screen displayed on my monitor, piece of my wall (behind it, supposed to be white) and a piece of furniture (the right part, also should be white). The monitor is LG 23MA73D-PZ, with IPS panel, calibrated to what I believe should be around 6500K (setting Colour Temperature = Warm2).
Left column shows a photo taken in the middle of the night, with lighting by LED lamps having 3000K color temperature. Middle column is the same scene lit by different LED lamps having 6500K. Finally, right column show a photo taken during the day, using only sunlight.
The only remainig variable is white balance of the photo itself. That's why I introduced two rows. Top row show all three photos calibrated to same white balance = 6500K. As you can see, the image on the screen looks pretty much the same on all of them, because monitor emits its own light. But the wall and the furniture, lit by a specific light source, seems orange or reddish on the first photo, while on the other photos it's more or less gray.
Our eyes, as well as cameras can adjust to changing color temperature to compensate for it and make everything looking neutral-white again. So the second row shows same photos calibrated to white balance of the specific light source. Now the wall and the furniture looks neutral gray on all of them, but notice what happened with the image on the screen when light was 3000K - it completely changed colors of the picture, making everything looking blue.
That's why it's so important to consider color temperature of your light sources when working with color correction and grading of photos, videos or some other graphics. Otherwise you can produce an image that looked good at the time of making, but turns out to have some color cast when seen under different lighting conditions. Of course, if you just work with text or code, it doesn't matter that much. It is more important then to just have a pleasant lighting that doesn't cause eye strain, which would probably be something more like the 3000K lamps.
# Blender 2.5 - Programming Export Plugin
Today I've been familiarizing myself with Blender 2.5. This new version is still in Beta stage, but as far as I can see everything is aleady in place and the program works OK. I only had to solve one problem at the beginning - my Blender was crashing at startup, because it was looking for PYTHONPATH environmental variable and thus trying to use old version of Python language that I had installed, while new Blender needs Python 3.1. The solution is to clear this environmental variable so Blender can use its bundled Python distribution. I've created a batch script to do this, called "Run Blender.bat":
"c:\Program Files\Blender Foundation\Blender\blender.exe"
Many changes have been made in new new Blender version. Fundamental concepts stay the same, so we still have Object Mode, Edit Mode, select objects with right mouse button, grab with G, rotate with R and scale with S. User interface is still nonstandard with all its non-overlapping and non-modal philosophy. But they introduced some new features and made quite big changes to the interface, so it took me some time to play around and discover where is everything now and how it works. Readings on this topic I'd recommend are the new manual for Blender 2.5 and especially Blender 2.5 Changes - a document that highlights what's new.
The function that I've spend much time searching for was showing normals, so in case you also need this and can't find it: 1. You must be in Edit Mode 2. Click on the small (+) symbol in the right-top corner of the 3D View to expand a panel with some parameters 3. In this panel, look for Mesh Display / Normals section and select the checkboxes you want.
When it comes to writing plugins, Python API has been completely redesigned. Information about it can be found in Introduction, Manual and finally Reference. I couldn't find any article about writing export plugin for Blender 2.5, but basing on the information I could find and the source code of the existing plugins I've managed to code one. Here it is: io_export_json.py. It exports some of the data (scenes, objects, meshes, vertices, faces, edges, normals, texture coordinates, vertex colors) in JSON format.
BTW do you know any good program to view JSON documents as a tree? The best I've found so far is JSON Viewer, but it's not ideal. For example, it can't open files so the document has to be pasted via the clipboard.
Blender keeps Python plugins in the user's directory. In my Windows 7 it is C:\Users\%MY_LOGIN%\AppData\Roaming\Blender Foundation\Blender\2.54\scripts\addons. To start using new plugin, you have to:
# How to Equally Blend Multiple Images in GIMP
During my today's walk on Warsaw I took many different photos. Some of them were series of photos of a road from exactly same place, with a purpose of merging them together into a single photo. My idea was to just average the color of each pixel, so it should be like:
out = 1/4 * (img + img + img + img)
But how to do this in GIMP? There is no such filter AFAIK. An obvious solution is to use blending - Mode and Opacity settings for layers - but it turns out to be not so simple. Each layer blends with a merged image from beneath it, so instead of average formula above we have to refer to a formula for blending (linear interpolation), which is:
out[i] = t[i] * img[i] + (1-t[i]) * out[i+1]
i is a layer index 0..(n-1), indexed from the topmost layer,
t[i] is Opacity parameter for layer i.
After expanding it for 4 layers, the formula becomes:
t * img0 + (1-t) * (
t * img1 + (1-t) * (
t * img2 + (1-t) * (
t * img3 + (1-t) * 0
Finally, after doing some math with pen and paper, I calculated that to equally blend (average) n images in GIMP, you should:
By the way, I've found a website where panorama photos can be uploaded for free and interactively viewed using just Flash. Here is my profile: reg | Panogio.
# Color Names in .NET - CheatSheet
Some color values used in computer science have their names, like "Red" (#FF0000) or "Navy" (#000080). You probably know them if you've written anything in HTML. But there are more of them than just several most popular ones, made of values 0x00, 0x80 and 0xFF. I've prepared (or rather, to be honest, copied from MSDN Library) a table of color names available in .NET standard library, as static variables in System.Drawing.Color, System.Drawing.Pens and System.Drawing.Brushes classes. Here is my "Color Names in .NET" CheatSheet:
# Tiny Planet
Tiny Planet is an interesting effect to be made from a photo or drawing. I saw it for the first time at Wojciech Toman's devlog. Here are some tiny planets made by me recently:
To make a tiny planet, you have to first take a 360 degrees panorama photo of some landscape. For stiching photos into single panoramic one I recommend free application from Microsoft Research called Microsoft Image Composite Editor (ICE). Of course there are many others availble. Then the process involves some manual graphics work and/or smart usage of some filters, where the crucial one is converting image to polar coordinates. In GIMP you can find the appropriate menu command in Filters / Distorts / Polar Coordinates.
The biggest question when making such images appears to be how to fill the inside and the outside of the circle forming surface of the planet. Do you have any ideas better than the ones I used here?
# Beautiful Wallpapers on Flickr
Yesterday I've found Flickr profile of Reciprocity - Alan Jaras - a research scientist and microscopist playing with photography of caustics and other light effects. Of course it's all the matter of taste, but for me his photos are really amazing. They look so abstract and so natural at the same time. Just look at the galleries Taming Light, Bending Light and Twisting Light. I think it wouldn't be easy to procedurally generate such images. Also check out his Favourites for more unusual images.
# Dithering i inny postprocessing
Dziś dalej bawiłem się w pisanie efektów postprocessingu. Szczególnie zainteresował mnie Dithering. Ta technika była stosowana do polepszania jakości obrazów w czasach, kiedy komputery dysponowały ograniczoną liczbą dostępnych kolorów. W szerszym kontekście Dithering oznacza celowe wprowadzanie szumów do sygnału celem zniwelowania nieprzyjemnego efektu powstającego w wyniku kwantyzacji do pewnej, małej liczby możliwych wartości (np. tylko kilka bitów na składowe RGB piksela czy próbkę dźwięku).
Dzisiejszy DirectX już nawet nie obsługuje palet, ale pomyślałem sobie, że napisanie takiego efektu renderowanego w czasie rzeczywistym za pomocą shaderów to będzie ciekawa część poznawania zagadnień związanych z tematem efektów pełnoekranowych i Non-Photorealistic Rendering.
Zasada działania takiego efektu jest stosunkowo prosta. Jeśli w kodzie shadera HLSL mamy dany kolor piksela Color.rgb, to możemy zmniejszyć precyzję każdego kanału do tylko 2, 3, 4 itd... możliwych wartości (g_DownsamplingFactor) za pomocą takiej operacji:
float Bias = 0.5; Color.rgb = floor(Color.rgb * g_DownsamplingFactor + Bias) / g_DownsamplingFactor;
To 0.5 służy do zaokrąglenia części ułamkowej, zamiast jej obcięcia. Jeśli teraz to przesunięcie 0.5 zastąpimy przesunięciem losowym w zakresie 0..1 (bez wartości skrajnych), to otrzymamy Dithering. Oto efekt: