My guess is that they've got 11 bits on 2 of the LEDs and 10 on the other, and the device values they present to the device produce specific electrical values at the LED and that's that. We could imagine that maybe it's linear or whatever. Point is, there's some sort of mapping from 32 bit device values to the characteristics of the dot on paper, and I bet that mapping is fixed. I assume that 0,0,0 is a damn good imitation of the paper's DMax, and actually I bet there's a whole lot of device value space that smushes down to the paper Dmax. Ditto 2048,2048,1024 being paper white.
Since they're got an enormous amount of room in that device's space, even if it is a fixed mapping and maybe not even a very nice mapping, they can still fit whatever mapping you like onto it.
So, among other things, they can manage a perfectly neutral middle grey.
Who knows, maybe they can custom map each of the 576 LEDs to compensate for variability in the LEDs themselves. With that much room to play with, why not?
I think this is a pretty good summary of what I was trying to convey.
To take the blocks/ process steps:
We take 8-bit (24-bit) colour data, along with the data’s colour space (.icc) and pass it into our RIP (ColorGATE).The RIP resamples the data within the file and converts the input 24-bit colour with its colour profile into the CIELAB profile connection space (PCS). The output device’s profile (the media specific.icc for our printer) is then used along with the selected rendering intent is used to convert from the PCS to the device specific RGB values in 24-bit colour. The result is a 24-bit colour (.bmp) at 400dpi.
The embedded printer driver convert from (.bmp) to print-specific data for driving the LEDs. The 24-bit pixel colour is channelised into its 8-bit composite data. On a per channel basis (R,G,B), the media specific calibration data is applied. In simplistic terms, this calibration data is a lookup table that has 0-255 on its input, that selects a 10/11 bit calibrated output value per input value. E.g. Input R=250 could lookup an output value of 967(10bit) or 1897(11bit). These 10/11 bits per channel are then re-combined to form the 32-bit time pulse exposure value for that pixel.
Why do we need all these bits? Well, the answer is that you, as a photographer, want a linear CIELAB response in your print. If 0,0,0 is paper white, and 256, 256, 256 is DMax, then 128,128,128 should be half-way there, and 64,64,64 should be 25% density and so on.
As I said in an earlier post, one of the problems that we have to contend with is that AgX photo paper is non-linear. Sometimes, a 1% increase in energy from the LED will generate a 1% increase in density of the colour on the paper. At other times, the ratio is completely different. It varies all along the curve, with some areas being particularly sensitive and others particularly insensitive. This variation is also subtly different between the three channels.
Finally, achieving a neutral gray at different points involves mixing
different ratios of C, M and Y dyes on the paper. As I said, as a user, you want a linear increase in the RGB values in your image file to produce a linear response (As measured in CIELAB with a D50 illuminant) on the paper - ie if input values imply a doubling of density, that’s what you want to see on the paper. So we need to map linear data from the image file to non-linear inputs to the LEDs in order to achieve the correct linear response on the paper (as far as possible).
Having the extra bits in the LED control levels allows us to achieve more precise control of the LEDs to achieve the best possible grey. This is not about using the extra bits to achieve a different colour; it’s about using that extra sensitivity to fine tune the relationship between the 3 channels at each point in the curve to achieve the most neutral possible gray. Understanding how each different paper reacts all along the gray line is what enables us to build our target files for each paper which is (as I said in one of my first posts) something that not even Fuji appears to have done. Our target files are designed to deliver a linear neutral grey when measured in CIELAB with a D50 illuminant.
Once we have the correct mapping to produce a neutral grey line that generates linear outputs from linear RGB 8-bit inputs we can extrapolate that to the rest of the colour space. So you have a look-up table that takes 8-bit input values and generates outputs in 10-bit or 11-bit for the LEDs for the whole of the paper gamut. Again, the key is to turn linear 8-bit inputs into linear 8-bit outputs on the printed page, but to do this you have to have non-linear mapping to 10/11-bits for the LEDs and the relationship between the three channels will not always be what you expect.
There are a number of factors that complicate this still further:
First, as many will know, where is even a point on the paper where if you pump too much energy in, it will actually become lighter (‘solarisation’). The response of the paper at this point is unpredictable. Fuji Professional paper’s limit point is, I think, a DMax of 2.5. Above this, you start to get solarisation. So understanding the DMax for the paper is fundamental to the calibration.
Solarisation info for anyone interested:
https://books.google.co.uk/books?id=WEkzDwAAQBAJ&pg=PA126&lpg=PA126&dq=solarisation+silver+halide&source=bl&ots=qvKPEdlg6-&sig=X3i9EifRJOOi6RvC8aF4Tw1Xzmg&hl=en&sa=X&ved=0ahUKEwjBisro09fZAhWHOsAKHZTeBWEQ6AEIUDAH#v=onepage&q=solarisation%20silver%20halide&f=falseNext, there is the question of cross-talk. In order to activate yellow dyes in the paper, you pump in blue light. However the magenta dye is also very slightly sensitive to this blue light and a tiny amount is also activated. At first, this is unnoticeable, but as you approach DMax in the blue/ yellow channel, the rate of yellow density increase begins to roll off. At the same time, the magenta dye has been activated and starts to become much more sensitive in its response to the blue light and more of this magenta leaks out. This is a known ‘feature’ of Fuji papers and results in a slightly orangey tone to very deep yellows. We have spent a good deal of time trying to minimise this.
Then there is the matter of the LEDs themselves. They are all slightly different and they all have slightly different power outputs. We need to account for that - for a given time pulse, each LED will give out different energy. They each also vary slightly in output wavelength and we have to deal with that, too. So we do control every LED individually and this is a crucial part of the calibration process.
So to summarise, the fact that we have 32 bits to play with in terms of LED input values is not aimed at producing more than 2^24 output combinations (ie 8-bit). It is all about mapping 2^24 input RGB values to 2^32 LED input values to allow those LEDs to generate 2^24 output values so that what you see on the paper is what you expect to see from the screen. We are using the fact that we have finer grain control in two areas: (i) in the gray balance; and (ii) in the LED balance to ensure that each LED is balanced relative to its peers. We need the extra bits to do this accurately.