XYZ 12bit test chart

[marcogiustini]

Hello Carl,

My first post here. First, let me thank you for the amazing job behind DCP-o-matic. I've always known DCP-o-matic but always used other software as I though it would give me more control. Then tried DCP-o-matic again recently and it's just awesome!

Back on topic: I would like to create a series of test charts with very accurate colours - for projector calibration. Carsten has been very helpful with me (thanks!) on a different forum and I understand that I have two or three options:

1. find a software that allows me to dial the XYZ 12bit values and skip RGB to XYZ conversion completely
2. work out what the RGB values for corresponding XYZ are for Red/Green/Blue and hope that the resulting colours aren't too far away
3. Use some third party software to precisely control the XYZ output colours when they are being converted

Now, option 1 seems to be the best but I have still to find such software. I'll try a Photoshop demo as Carsten is suggesting that later version may allow the user to dial 12bit colours directly

Option 2 is what I have been testing this morning but due to my limited knowledge of the subject - not to mention my math skills - I haven't come up with much yet. I found (thanks again Carsten!) the pdf that documents how colour conversion happens in DCP-o-matic but I haven't been able to work out the math so that, given the target XYZ values, I get the corresponding RGB values to be used in my chart.

I was wondering if you could help me with the latter point - which, by the way, assumes that I can find the reference XYZ values for Red, Green and Blue. (edit, I've found them in the meantime, attached)

I hope you can help me, thank you very much for your time!

Marco

[carl]

Hi Marco,

1. find a software that allows me to dial the XYZ 12bit values and skip RGB to XYZ conversion completely

This strikes me as probably the easiest way... if you could get XYZ TIFFs (or something) into DCP-o-matic (or whatever) and do no colourspace conversion you should get what you want in the DCP.

How's your programming? I suspect you could use Python and something like this to create suitable TIFFs.

Going from RGB to XYZ is I think likely to end up with at least some rounding errors which I imagine you are keen to avoid. I think you'd have to go in reverse through the steps in the DCP-o-matic colour document, inverting the RGB -> XYZ matrix. Let me know if you need to do that and I'll have a go.

[carl]

As it happens I had to do this today for something else. This code:

Code: Select all

#!/usr/bin/python

from PIL import Image
import numpy
from libtiff import TIFF

width = 1998
height = 1080
filename = 'test.tif'

im = numpy.zeros((height, width, 3), dtype=numpy.uint16)

# Convert 12 to 16-bit
def pixel(x):
    return x << 4

# Bars of increasing intensity in X
for x in range(0, width):
    for y in range(0, height):
        if x < 400:
            im[y][x][0] = pixel(0)
        elif x < 800:
            im[y][x][0] = pixel(1024)
        elif x < 1200:
            im[y][x][0] = pixel(2048)
        elif x < 1600:
            im[y][x][0] = pixel(3072)
        else:
            im[y][x][0] = pixel(4095)

# Ramp in Y
for x in range(0, width):
    for y in range(0, height):
        im[y][x][1] = pixel((x * 4) % 4096)

tiff = TIFF.open(filename, mode='w')
tiff.write_image(im, write_rgb=True)
tiff.close()

makes a simple test pattern that you can import into DCP-o-matic. Set "colour conversion" to "none" and you should have more-or-less straight pass-through of X/Y/Z value. I haven't tested the end-to-end correctness yet myself.

[marcogiustini]

Hi Carl

Thank you, I appreciate your time on this matter!!

Creating my own full-frame charts is definitely useful (I can make a greyscale, which I haven't seen 'ready' on the field), I'll try diving into Phyton taking your script as an example (my programming is bad, but I can try and improvise, I think I got how your script is working!).

However for what I have in mind I'd like to make something more complex than a white field. And I agree that converting from RGB cannot give perfectly accurate colours. I have been looking for something that deals with 12bit colours for a while but so far I haven't had luck.

Thanks for offering to invert the RGB to XYZ matrix for me. Let me persist on the other option, failing that I will gratefully appreciate your help again!

Carsten mentioned that you are going to improve the vectorscope with a tool to display the values of the colours. I don't mean any rush of course, but I was wondering how far from being developed is that?

Thanks!

[Carsten]

Hi Marco,


did not have the time to dig into this myself. But wondering wether ImageMagick could do it, as it has support for basic drawing functions. Wondering wether you could have it use xyz internally. I am not that familiar with it, though.

My outdated Photoshop doesn't allow me to use 16Bit color picker. I have to see wether the more recent CS versions do. Recent versions of GIMP (from 2.9 up) would be worth another try, as they support 16Bit per color component as well.
I still think that's the easiest way, as you wouldn't even need to care about XYZ from the software side - create 16Bit RGB numbers, bypass color transform in DOM, that should transfer these 16Bit numbers (rounded to 12Bit) straight into the J2K. All you need to do is to calculate the right 16Bit XYZ numbers for your task.


The XYZ mouseover display has been assigned by Carl in the bug/feature database:

http://dcpomatic.com/mantis/view.php?id=932

- Carsten

[marcogiustini]

Thanks Carsten

Good idea, I'll have a look at Gimp and Imagemagik. (I did check Gimp some time ago but it's been a while).

yes, hopefully I could create a full field colour patch hacking the script Carl used, I was hoping to create a more elaborate framing chart - e.g. a uniformity grey-80% chart with 9 squares to align the colour meter. But if that's not doable, a full frame will do. I will try and make something soon.

Thanks for your help in the meantime!

[carl]

Carsten mentioned that you are going to improve the vectorscope with a tool to display the values of the colours. I don't mean any rush of course, but I was wondering how far from being developed is that?

It should be there within a week or so. Keep an eye on the bug tracker (or subscribe to the bug to get email updates).

I'm just trying to work out exactly what you and Carsten are after here; see the discussion on Mantis.

[marcogiustini]

Hi Carl,

That's great news thanks.
What I am looking for is a tool to confirm that the chart I am feeding to DCP-o-matic is indeed the XYZ values I want. However, that was mostly for when I was going to do some guesswork using 8bits or 16bits coordinates. If I can dial the 12bits colour directly in a script, it may not be as critical.

After several hours I've managed to have python and all the required libraries working and I managed to run your script which produced a picture.

I will now play with the script and see if I can create the patches I want. Just one question if you please: so far I am unable to find documentation for the 'im[x][y]0 = pixel [xxxx] you are using. I guess it's something that writes each individual pixel (which are looped by the FOR line) but I haven't foudn the relevant docs and still haven't grasped the meaning at present. I'll keep experimenting but if you have a link to some online help that'd be great.

Thanks again for the huge support!

Marco

[carl]

I will now play with the script and see if I can create the patches I want. Just one question if you please: so far I am unable to find documentation for the 'im[x][y]0 = pixel [xxxx] you are using. I guess it's something that writes each individual pixel (which are looped by the FOR line) but I haven't foudn the relevant docs and still haven't grasped the meaning at present. I'll keep experimenting but if you have a link to some online help that'd be great.

pixel() is a function defined above the loops (at

Code: Select all

def pixel(x)

). It converts a 12-bit value into a 16-bit value. So

im[y][x][0] = pixel(42)

means write the 12-bit value 42 as a 16-bit number (shifted up 4 places) to pixel x,y in component 0 (the X in XYZ). This will put 42 into the DCP when you put the TIFF into DoM, as it will throw away the lower 4 bits and convert back to 12-bit.

Does that make sense?

[Carsten]

Meanwhile, I found out that even the latest version of photoshop does not allow to enter 16 bit values for RGB components. You can display pixel values as 16 Bit numbers, but you can not create colors with 16 Bit precision. Weird...
It would be very cumbersome to tweak 8Bit values into your desired 16/12Bit target values with PS. Unless there is a special trick (like a 16Bit capable lookup table color mapping plugin), Photoshop seems to be useless here.


- Carsten