Better display quality, printing and the quest for 10 bit colour support

Since I got a nice display (dell U2713H) and got it properly set up I have a good reliable photography workflow on Windows, and with a little work I have the monitor working nicely on Ubuntu as well (This particular monitor requires a pixelclock fix to enable Ubuntu to drive native resolution through the nVidia drivers - see below the break).

My hardware setup is:

• Asus P8Z77-V LE motherboard
• Intel i7-3770
• nVidia GTX 660 Ti graphics card -> display port / hdmi
• -or- 
• sometimes Intel 4000 graphics -> display port
• Dell U2713H monitor

I use D S Colour labs for all my colour printing and can get pretty well perfect match between print preview in Lightroom and the resulting print viewed in a viewing box. However even with Lightroom / Photoshop I still sometimes see banding while working on photos  and it is easy to show that this is often due to the 8 bits / colour / pixel that is normal for today's computers.

(To see this just make a new image in an image editor and fill it with a gradient with a fairly restricted range of grays, such as from 55 - 65. I was surprised when I first tried this just how obvious the effect is.)

So I started looking around to see if I could get at the 10 bits / channel that my monitor is capable of.

At first it appears that the only way to do this is to by a professional workstation graphics card, but these are dramatically more expensive than their consumer equivalents. Then I found that the nVidia Linux drivers are fully 10 bit capable (usually referred to as 30 bit color) on all relatively recent cards!

Just a quick build for a client to play nice music

Now that I have minimserver working well and have found sensible playback software, here's a quick note on a basic build for a client to act as a upnp renderer with optional control and chrome installed for netflix access.

Maybe the time has finally come to do the media server thing

I've been keen on the idea of a media (primarily music) server for a long time, but the completely turd like control facilities have always been a show stopper. Mainly 'cos as I have a fair sized collection of classical music, the lack of ability to handle the distinction between composer, performer, orchestra, soloist etc. - at least without spending a fortune on Linn or other proprietary kit.

At one time I seriously considered a fully diy solution, but that was too big a commitment.

My most recent foray was with plex, but this still didn't solve the indexing problem.

Then yesterday I bumped into minimserver. This looked like the sort of answer I was looking for. It looked like it properly handles the indexing and access.

What I want to do is:

1. media on a headless server (probably a vm on my pet server)
2. control agents preferably on android
3. playback through windows or ubuntu pc's (or even android things)

Still early days, but things are looking promising so here is the log of my first steps.

Shooting in raw pt 2 - Panasonic DMC-FZ1000

Continuing the story of raw vs jpeg, here are some photos from a Panasonic Lumix. The jpeg processing here is very different to the canon - and preserves more detail especially in the well exposed areas. But the opportunity to recover very dark and very bright areas is still greatly reduced when starting with a jpeg.

Yes you really should shoot raw, and this is why.....

I've just been looking at some photos taken by a friend from camera club, he was trying to find out if taking photos in raw really makes a difference compared to using jpeg. In short yes it does, and now I've looked at some photos, it makes even more of a difference than I had realised, not just more chance to see the highlights and dark areas, but more detail and better colour rendition as well.

While there may still be occcasions when jpeg is a good idea (fast auto repeat without filling the buffer, or just to take an enormous number of pictures with limited memory card size), use raw unless you have a  good reason not to.

Openhab on Raspberry Pi - its a bit slow

I have been hoping that if a waited for a while, the performance problems of Openhab on a Raspberry Pi would get sorted, but no such luck, so it might be time to get out the old wheel tapper's hammer and see what's going on.

DOF and diffraction part 2 - the software: hugin, photoshop and helicon focus

As soon as I looked a little harder at the output from enfuse, I realised that there were some strange things going on....

This first crop is the output file which at first glance looks promising - the card and the distant hedge are both looking reasonable,but there is a bit of a dark halo around the black lines as well as a thin line in the centre of the black line which is darker than the rest.

Here is the image from the stack where this card is in focus. not only is the strange halo absent, but there is a lot more texture detail showing up in the card surface.

Clearly there is detail in the stack that does not make it through the process... 

Here is a quick go with two other obvious contenders for focus stacking:

photoshop CC

Helicon Focus

The output from Photoshop CC, which claims to be able to focus stack, but in reality make a complete mess of it. This crop shows that it has failed on the distant hedge immediately above the card and also there are some wierd things going on with the railings.

the output from Helicon focus using all default settings. This looks much more promising - there is a small area of softness immediately around the card, but this is where the distant focus image has blurred white from the card into the foliage, so this is actually a sensible default.

I gave CombineZP a quick go as well, but it crashed most reliably on all but the simplest mode, and in that mode it's output was nowhere near as good as Helicon.

Read on for info on how enfuse and photoshop get it so wrong, and why Helicon focus looks to be the best option.

the dof and diffraction trade-off

Sometimes physics is a real bummer, and trying to win depth of field to maintain crisp images for things near and far (especially with longer focal lengths) quickly falls into the pit of diffraction, which just makes everything go soft.


So how bad is it really and what can help? I'm exploring some of the options with my 70-200mm zoom. I set up a simple test scene along the side of the house (facing north so no direct sun, although mostly cloudy anyway..). Hopefully this will develop into a method for using DSLR-controller to take the pictures, and then hugin tools to automate the blending process.


Here are the limits of what happens, these are crops from a MUCH larger photo basically out-of-camera, and F32 is really loosing a lot. These crops are from the little square towards the bottom left of the picture.

. .

F2.8

. .

F32

Razberry: lets do temerature logging and a graph...

I've just updated to a recent 1.4 snapshot and added in HABmin to the config without any real difficulties, so time to see if I can persist the temperature data and do a graph I think.

oh yes, balls are the way to do it

or the use of styrofoam balls to evaluate light sources.

After thinking about ways to evaluate softboxes, brollies and the like, I decided to try polystyrene balls as a target to better see what is going on and it works really well.

 Here is a set of balls I got from hobbycraft - middle sized and big ones alternating - hanging in front a bare naked flash (Yongnuo 565), set to 24mm with the diffuser in place.

The balls are all lit with a hard edge around the circumference of each ball, there is a little reflected light showing from the white ceiling and other balls, but not enought to matter really. Below is a zoom in on the centre 3 balls.

CrashPlan on Raspberry pi - not such a good idea?

I continued to try to make Raspberry Pi with CrashPlan a viable backup server, but after running it for a few days and looking for various ways to  make it more robust, I've decided to give up on this and run CrashPlan along with a few other services on a baby server. Explanation follows.....