# Sony ARW embedded CA corrections – SOLVED (kind of…)

In my last post, I documented my findings on where Sony embeds CA-corrections in their ARW-files but couldn’t figure out the encoding. With some more try and error I have now partially solved this and can reproduce the Adobe’s DNG-converter’s radial transformation functions parameters (to a certain level of precision), which is what I wanted. I still don’t fully understand the exact meaning of the values – so if somebody wants to dig in further, there’s still work to be done…

As I wrote, Sony uses 16 signed 16-bit integers to encode the CA-correction for one colour plane. Adobe’s DNG converter transforms those 16 integers into 4 double-precision floating point numbers (p0-p3), encoding a radial transformation function $f(r)=p_{0}+p_{1}\cdot r^{2}+p_{2}\cdot r^{4}+p_{3}\cdot r^{6}$.

Turns out that each of the 16 individual tag-number describes one such $f_{t}(r)$ function (with t being tag [0-15]), scaled according to the number given. The final transformation function $f(r)$ is then the sum of the 16 individual functions.

Given that each tag-value always seems to be a multiple of 128, if we can describe 16 “base-functions” $f_{t}^{base}(r)=p_{t,0}^{base}+p_{t,1}^{base}\cdot r^{2}+p_{t,2}^{base}\cdot r^{4}+p_{t,3}^{base}\cdot r^{6}$ with only one tag t set to 128 and everything else to 0, we can easily calculate the final function as follows

$f(r)=\sum_{i=0}^{15}\frac{t_{i}}{128}\cdot f_{i}^{base}(r)$ with $p_{[0-3]}=\sum_{i=0}^{15}\frac{t_{i}}{128}\cdot p_{i,[0-3]}^{base}$


(The above is not fully correct, since you need to subtract/add 1 from $p_{0}$ before/after the operation).

How do we get the parameters $p_{t,[0-3]}^{base}$ to describe the base functions? Here they are:


t	        p0                 p1                 p2                p3
0	1.000000000000000 -0.000000000000003  0.000000000000004  0.000000000000000
1	1.000002185924800 -0.000013742120879  0.000024331123832 -0.000012881183203
2	1.000008015306730 -0.000049514864695  0.000086817490976 -0.000045679490013
3	1.000015476524690 -0.000092372857099  0.000158805754548 -0.000082507850262
4	1.000021771704520 -0.000121922077811  0.000201673293326 -0.000102132667907
5	1.000024066033500 -0.000118380587996  0.000179036891600 -0.000084963746248
6	1.000020370946620 -0.000069640192430  0.000070863379852 -0.000021085470984
7	1.000010395330620  0.000022094319767 -0.000113499274789  0.000082425461175
8	0.999996151504952  0.000135918385120 -0.000327203799781  0.000197151826958
9	0.999982055351825  0.000232330029149 -0.000487383601737  0.000274714579025
10	0.999974212580889  0.000260464758777 -0.000491767996422  0.000257137217849
11	0.999978535726942  0.000175513032767 -0.000256821636478  0.000099955930692
12	0.999997289092430 -0.000030222967688  0.000215351050453 -0.000187663058249
13	1.000023611459520 -0.000278769872875  0.000733243740232 -0.000481036136103
14	1.000033519009740 -0.000336150894464  0.000766383874106 -0.000451040811218
15	0.999974843502193  0.000284395910313 -0.000759830289663  0.000557605398484

Now we can easily calculate the final transformation function based on the tag values. With the example from last post, it looks like this:

Where do these base-values come from? No idea. However, it’s highly likely that they themself can be calculated – plot the base parameters across the base functions and what do you get…?

…one polynomial transfer functions with 4 different scalings. So, it seems that these values are derived from another 4 values, maybe specified in some other tag or–more likely–fixed (the base values seem to be constant across the different photos and lenses that I tested).

The above solution works for my purpose but is not ideal, since it loses precision by using the precomputed decimal values. If somebody wants to figure out the parameters for the base-functions to allow for calculation with full precision, be my guest (I tried Excel-solver but gave up quite quickly…).