RosemaryD wrote:It's lovely. I'm sure I've said before but you must be more than a little pleased with your charting program, with results like this.
Yes, I am happy with my charting program, but it is slowly highlighting a problem. I am using public domain values for the red, green & blue colour components of the DMC threads. As far as I can tell they trace back to an unofficial release by DMC (and it seems to have been made unofficial so they couldn't be held to it contractually). There seems to be a bit of a problem with the accuracy of these colour definitions. I know that sounds bad, but I'll try to explain what I think has happened.
Digital images can give component values for the red, green & blue components within the range 0 to 255, thus enabling 2^24 possible graduations of colour, or more different colours than most humans are able to resolve. It is defined that absolute black is 0/0/0 for Red, Green & Blue, while with brilliant white has all component values at 255/255/255. The problem comes in that real thread colours do not cover the whole range, because brilliant white still absorbs some incident light and does not reflect 100% of the light impinging on it. So the component values if you photograph brilliant white may be 239/239/239 (I have done this to see the numbers). Then, because black thread does reflect light, and not absorb every photon that impinges on it, the component values are 8/8/8. As a result the range is squashed a bit, covering 231 divisions of the possible 255. Seeing this, I think the originator at DMC shifted & stretched the colour values using a formula similar to that below:
- New Component Value = (Original component Value - 8 ) * 255/231
This then stretches the range to give black = 0/0/0 and brilliant white = 255/255/255. That enables all digital photos to be mapped easily against the thread colours.
BUT there is a problem with this simple idea.
The light end of the range is stretched more than the dark end. The dark end of the range is stretched 8 divisions out of 255, while the light end is stretched twice as far, meaning that on average the thread colours in the thread definition file will be lighter than the real threads. So, when you convert the colours, the stitched picture seems darker than the digital image.
I am not completely happy with this. I feel that there should be no compromise over the colours, and consequently the thread definition file value should be as close to the colour of the actual threads as it is possible to get. That way the mock-up of the converted image would be functionally identical to the stitched image. There are two consequences of this:
- The bright sections of the photo may seem to be slightly washed out & lacking in detail, as there will be fewer thread colours in the brighter range of the colour component values and
- I will have to purchase every thread colour, stitch a 10x10 block and photograph the whole piece with all 447 colours in one go before I can get sufficient real data to be 100% certain I have the best basis for my colour component list.
The big problem with this is the time it's going to take & the fact I don't yet have every colour.
I have done something similar with the Anchor Range of colours, in that I downloaded an official Coates pdf of the Anchor floss card that uses threads, and harvested the average colours off the card (using the part of my program where you can create a thread definition file). This then ensures the shadow cast by the thread is included in the average colour - which is also part of the colour you see in the cross stitch picture. I have not altered the Public Domain DMC colours, but I do now offer an optional adjusted DMC range that makes the thread definition component values 10% darker, which I think goes some way to solving the issues.
So to summarise all my waffle above:
I'm happy with the program. It is now sufficiently accurate in its conversion to highlight the relatively small errors introduced by assumptions made in generating the reference data. From now on, in order to make the program better, I am going to have to improve the quality of the reference data. And that's hard work.
Regards,
Richard.