A result from the trip to Moritzburg with Jana and Dirk. In blue the impression is very different to the original, as all the colour contrast is missing. Unfortunately this is one of the Cyanotypes were a digital reproduction is very hard. In reality the details are much better visible…
An experiment in every respect…
It's already a week ago that we've been to the fun fair (closed on Sunday). It's been fun as always with other flickrers and finally I've found some use in a fun fair (I'd never ride those things ;-)…
The shot of the ferris wheel above is the best of this session (although it might have been better in the blue hour). There are some other nice shots in the set to see, though.
Another result from flickr tour to Moritzburg. The original can be found on flickr…
The original photograph was taken on saturday on our flickr tour to Moritzburg using my Lensbaby 2.0 (reminder: write an entry about this nice piece…). Although the sweet spot didn't catch anything in particular, it somehow fits this image very well (and it does even better as Cyanotype).
Google will win and rule, but do you want this scenario really to happen?
It is scary…
I don't think there's a way back, but for the geeks, who'll use technologies consciously and know how to protect their privacy (if and when they want it). And if Google won't “win” some other company will.
Why I found this now? Well, I'm just looking for solutions to store much data online (backing up my photo storage including RAWs which are 6 DVDs currently). It would be so good to have another place to save this, I can't imagine loosing all this data…
Yesterday I've been on tour with two other crazy flickrers: Dirk aka derbaum and Jana aka [+]maggie. What a funny day! The best 42 of about 330 are on flickr
1. It's Already Starting, 2. Church, 3. Lamp, 4. What Do We Do Now?, 5. [+]maggie, 6. derbaum, 7. Drops, 8. Fountain #1, 9. Details, 10. Fountain #2, 11. Surreal Splash (aka Fountain #3), 12. [+]maggie at work, 13. Inscription, 14. Deamon..., 15. Looking Up, 16. Detail, 17. Personal, 18. derbaum, 19. Adjoining, 20. Forest, 21. Yellow, 22. Making Of, 23. Making Of?, 24. Inside, Not For Visitors, 25. What's So Interesting Here?, 26. Shoot, I'm Posing!, 27. For A Real Flickrer, Everything Is Worth A Shot!, 28. Mirror, 29. Tail Light, 30. Decaying Castle, 31. No Window, 32. Hey, Let's Have A Look!, 33. It's Still Going On, 34. Looking Up (Again), 35. Brennnesseln für die Gurkenbande, 36. Pay Office, 37. Rusty Ring, 38. Old Sign, 39. Forms, 40. derbaum, Raising Dust, 41. Peeking, 42. 42 — Looking Up (Again And Again)
It's really fun being on photo tour with people having the same “adiction” as you. You can take your time, test this and that, change lenses, shoot other photographers in funny positions, nobody's rushing…
And here we're, three photomaniacs (courtasy of [+]maggie):
Thanks a lot you two for this wonderful day!
Until now the pad was the only thing that didn't work for my Wacom Graphire4 on Linux. For the Intuos3 exists a small application expresskeys. I decided to adapt this tool.
As the Intuos has a quite different button setup compared to the Graphire4 I decided to use expresskeys as a base but instead of adding the functionality for the Graphire4 , removing the Intuos3 stuff.
A preliminary 0.1.0 version (which works for me) is downloadable here: gr4_buttons-0.1.0.tar.gz.
Most of the files still refer to expresskeys (and maybe these changes will be included there).
Unpack the file, run ./configure; make and maybe make install as root if you want to install it.
If I refer to Your_Pad you have to substitute that with the identifier that is defined in your X configuration (usally xorg.conf. There you have an InputSection like this somewhere:
Section "InputDevice" Driver "wacom" Identifier "Your_Pad" Option "Device" "/dev/input/wacom" Option "USB" "on" Option "Type" "pad" EndSection
Use whatever name you defined there.
Call gr4_buttons Your_Pad (replace Your_Pad with the name of the device defined in the X configuration) and kill it hiting Ctrl-C. This way you get the standard ~/.gr4_buttons/gr4_buttons.conf.
The top documentation still is for expresskeys but if you want to add a special configuration for another program, copy the block below and be aware that this is untested!.
The standard configuration looks like this:
00 Program Name: "default" 01 Scroll Wheel Up: 994 02 Scroll Wheel Up Plus: 0 03 Scroll Wheel Down: 995 04 Scroll Wheel Down Plus: 0 05 Left Button: 64 06 Left Button Plus: 0 07 Right Button : 37 08 Right Button Plus : 0
This configures the scroll wheel to send mouse button 4 on an up move and mouse button 5 on a down move (994 and 995 are virtual key codes to send buttons of the core pointer and button 4 and 5 are the signals of my mouse for the scroll wheel: have a look at the ZAxisMapping option of your core pointer in the X configuration). The left button sends Alt and the right one Control. Actually I don't have a good use for them now. If you don't want a signal, set them to 0.
Run it with gr4_buttons Your_Pad -v and it will show what happens.
Run it with gr4_buttons Your_Pad -d. This is the daemon mode. All you have to do now, is to setup an auto-run for X (add it to session management of GNOME, autostart for KDE, or include it into .xinitrc.
If I'll develop this small thing further, I'd like to change the configuration file format and I'd like to have a fallback mode, if you don't give a pad name: just use one found in X (the first one). A test if a Graphire4 is available would be nice as well. Maybe one could even fetch the ZAxisMapping of the core pointer and use the buttons found there as default configuration for the wheel.
Many thanks go to the developers of expresskeys (Mats Johannesson and Denis DerSarkisian) and all the autors of the linuxwacom project.
I got a new tool, a Wacom Graphire4
Quite a while ago, when I still used an analog camera, I already did consider buying one, because if you scan you get always some dust. But then I couldn't decide.
Now I decided to scan all the 15 films of my last big trip (to California) and again I have to remove quite a bit of dust. I try to clean the negative, but you never get it perfect and you have to do some work on the images you want to use.
From surfing the web I did know, that chances are good with Wacom tablets. So I didn't consider some cheaper alternatives but got for a Wacom firsthand.
Plugged it in. It worked. Somehow at least…
I did work, but as a mouse and I did have no chance to set it to absolute mode, which is the important thing. So I started reading at linuxwacom.
The tablet was captured as mouse. This way you have no chance of setting it up like a tablet (absolute coodinates, pressure, stylus and “eraser”). This is caused by the usbhid kernel module, which does grab it as mouse so that the wacom driver can't grab it (I still don't understand exactly why this happened on my system, see below). With newer kernels this problem could be solved (I'm not sure), but with 2.6.11.4-21.11 (which is the normal updated SuSE 9.3 one) it is.
First a small warning: if you have your keyboard attached to USB as well, you better have a PS/2 one at hand. This is good, if something goes wrong (as it did for me at first)…
SuSE 9.3 includes linuxwacom 0.6.6—pretty old. I decided to use the latest one: 0.7.3 (unstable version, I know). Tried to compile but it didn't work. SuSE kernel version are in /usr/src/linux-2.6.11.4-21.11-default but linuxwacom expects them in /usr/src/linux-2.6.11.4-21.11. Did set the link. Compiling worked. So I installed the kernel modules (usbhid.ko and wacom.ko), the programs, and the X11 module. As I use an USB attached keyboard, I didn't want to reload the modules by hand, in case I'm stuck in between, I could loose access to my keyboard…
That's why I restarted the PC…
The keyboard did work (what the f***)!
The keyboard doesn't work with the USB to PS/2 adapter my mouse used (maybe this one doesn't work on PS/2 by intention, but it was worth a try). Unfortunately I didn't have a PS/2 keyboard at home so I went to bed first…
Next morning I fetched a PS/2 keyboard from work (my old one) and started looking, whats went wrong.
hid-core.cWhat's included in linuxwacom on kernel level? It's hid-core.c and wacom.c (at least for 2.6.11). And loading of usbhid didn't work (it crashed with an error). So let's have a look at hid-core.c…
#define DRIVER_VERSION "v2.0 - 2.6.11.3-pc-0.2"
#define DRIVER_VERSION "v2.01"
Hm, a different version, apparantly the same version string as linuxwacom includes for 2.6.13.
hid-core.c from the 2.6.13 directoryLet's tell you first: it doesn't work, but why.
If you look at the code of some functions, you see, that an interupt parameter was added to some functions. I suppose SuSE backported the changes. Directly compiling didn't work, so I did try removing all the references to interupt (just a few lines of code to change). Compiling did work but the module wasn't usable…
hid-core.cI did just add some definitions, which might be needed for my Graphire4:
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_GRAPHIRE + 5, HID_QUIRK_IGNORE },
{ USB_VENDOR_ID_WACOM, USB_DEVICE_ID_WACOM_GRAPHIRE + 6, HID_QUIRK_IGNORE },
I ignored all other differences there might have been (so for an Intuos you might have to add some different defines as well).
It compiled without problems and it is running like a charm!
For all the rest (options for X and so on) see linuxwacom, it's well documented.
On Linux the pad doesn't work. I'd like to use the wheel, but as far as I understood all the documentation and discussion correctly, you could use it if you write your own application but you can't in general on X (yet?). Fortunately everything else works and this isn't too important for me.
It's a great tool I can only recommend for editing images! I even use it as mouse sometimes. Esp. if I scan I have to click often the same buttons. Even after a short time of using it I find the correct spot almost immediately. It takes still time to get used to hit widgets at the edges (like scrollbars or a toolbar) and not to move the pen while clicking. I definetly suggest turning on the KeepShape mode. That way a circle you draw is really a circle, but depending on you monitor you loose a part of the active area.
Even working on the desktop is fun. Drag'n'Drop is so much more intuitive using a pen: move it slightly over the surface just sets the cursor but touching down drags an object (or does, what clicking with the left mouse button would do.
It does work very well on Linux (you have one advantage: the erase is just a second pen, you can use it for what you like ;-), but at least on SuSE 9.3 it doesn't out of the box. It does a bit, but as it is doing the wrong thing for a table, this doesn't help (but it's somehow promissing, that this will be better some day).
Installation wasn't too bad, if you are an experienced user! At least not as bad as some things were some years ago (when you compile a kernel twice a week and was almost forced to if you changed some hardware; you just didn't compile daily, because you computer was too slow, didn't you?).
At least I didn't have to recompile a complete kernel, but I had to move the kernel and X modules to the right place myself—nothing for unexperienced users…
I'd really like to use it for LabVIEW programming (mabye even a Cintiq)! I suppose this would be just great (but I don't think I can convice my boss to spend money on one)… ;-)
