blog (11)

Monday, 05 January 2015 15:36

In the light box 2

Written by

It has been quite a while since I wrote about how I created a simple light box (Old article). I have recently been using it again and tried to improve the sharpness of the pictures. This was mainly triggered through my all new Canon EOS 60D that I wanted to explore. I came up with the following two pictures:

IMG 1212 making of

IMG 1223 making of


This is what I did:

I used the same light box as before without modification. I do not have professional light equipment. I used the ceiling lamp, a stand lamp and a desk lamp. As you can see in the second picture „The little drummer boy.“ the desk lamp created to hard light. I therefore used some plastic for diffusion. I shot the pictures in raw mode. Because of the difficult light setup, I had to adjust the white balance by hand. I used aperture value 11 and a zoom lens to gain a nice depth of field. I aligned the camera vertically for a nice navel perspective. To improve the sharpness of the image I used a tripod,  mirror lock-up and a remote trigger. I have been using the tripod and the remote before but I think using the mirror lock-up is what made the picture tack sharp. Even though my old EOS 400D also had this function, the EOS 60D makes it a lot easier to apply. One just has to turn on the live view. I normally don’t use the live view because it drains to much battery, though.


 In short:

  • Try to create soft light with diffusion and reflected light.
  • Aperture 11 (for good dept of field)
  • Use raw mode, especially when working with different light types
  • Use a zoom lens with the maximum zoom
  • Align the camera in the navel perspective
  • Use a tripod (for sharpness)
  • Use mirror lock-up (for sharpness)
  • Use a remote trigger (for sharpness)


Wednesday, 22 October 2014 18:29

How to create a 32bit word based hexdump on Linux

Written by

I have to work a lot with 32bit word aligned data. Unfortunately the hexdump tool included with linux uses byte or short alignment by default. I’ve wondered how to make hexdump to print 32bit words instead including an offset indicator as well as the hexdump typical ascii interpretation.

What I came up with was:

monte@mibix:~$ dd if=/dev/urandom bs=4 count=32 2>/dev/null | hexdump -v -e '"%08_ax: "' -e ' 4/4 "%08x " " |"' -e '16/1 "%_p" "|\n"'
00000000: 4d6ec4eb d5b8921d c3bd306a c0d20d1a |..nM....j0......|
00000010: 228d9a4c 4fd68ea7 6a837903 aca46e9a |L.."...O.y.j.n..|
00000020: 513e32f6 2cbc69db ca18bda0 d74bbe71 |.2>Q.i.,....q.K.|
00000030: b27cfd65 8859a08a db92a090 f81e301d |e.|...Y......0..|
00000040: 029a5e6c 23a3d621 ce35a06d e4b48cbd |l^..!..#m.5.....|
00000050: 2bba6da0 2e0c7f84 536eb6ad 94a4827b |.m.+......nS{...|
00000060: 17699fc1 2231d9d1 43210088 37f97a4c |..i...1"..!CLz.7|
00000070: e474aef3 23483fa7 b7f6ed41 cb01d18a |..t..?H#A.......|monte@mibix:~$ 

The dd command reads the data from a binary file. The block size (bs) is 4 so we read 32bit words. The count is 32 which means we read 128 bytes in total. We pipe stderr to null because we do not want to see the in/out statistic. The stdout output is forwarded to the hexdump command.

We specify the -v option to output all data as is. Otherwise hexdump would shorten equal data. The first -e format parameter tells hexdump to print the offset. The second -e format parameter tells hexump to print 4 times 4 bytes (which is 32bits) in the format with 8 nibbles and trailing zeros. The last -e format tells hexdump to print 16 times one byte as character interpretation. The %_p format will print a „.“ for each non printable character. Note that the last two -e formats print the same data. If you specify all formats with one -e you will get the wrong result.

Thursday, 10 July 2014 10:26

Windows Kernel Mode Wait

Written by

Sometimes you have to wait, even when writing a Windows driver. Well, waiting in kernel mode is a bad idea in general but sometimes it is necessary.

Today I stumbled over a code fragment which I know from my experience does not do what the programmer might have expected. The problem is the function KeDelayExecutionThread. KeDelayExecutionThread was used in a wait function which was designed to wait for any time in micro seconds. The value of micro seconds was passed to KeDelayExecutionThread multiplied by ten to generate a wait time in steps of 100 nano seconds.


There are two problems in this approach. First is that KeDelayExecutionThread waits for an absolute time event in case of a positive number. Thus to get the requested delay in micro seconds one has to specify a negative value. The second problem here is that KeDelayExecutionThread yields the process which leads to a very inaccurate delay especially for times smaller than about 50 milli seconds.


A better kernel wait function would call KeDelayExecutionThread or KeDelayExecutionThread depending on the situaton.


Maybe like this :  

wait( ULONG usec )
    ULONG ulReturn = 0;
    if( u_sec < 50000 )
        /* KeDelayExecutionThread yields the process */
        /* Waiting times lower than 50ms are not accurate */
        /* Because of this we need to busy wait here */
        KeStallExecutionProcessor( usec );
        LARGE_INTEGER waittime;
        /* specifies the wait time in steps of 100ns */
        /* Negative values specify a relative time offset */
        waittime.QuadPart = -1 * usec * 10;
        if( STATUS_SUCCESS == KeDelayExecutionThread( KernelMode, TRUE, &waittime ) )
            ulReturn = 0;
            ulReturn = 1;
    return ulReturn;