# 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 .

Turns out that each of the 16 individual tag-number describes one such function (with t being tag [0-15]), scaled according to the number given. The final transformation function 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” with only one tag t set to 128 and everything else to 0, we can easily calculate the final function as follows

with

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

How do we get the parameters to describe the base functions? Here they are:

t p0 p1 p2 p30 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…).

Hi! These functions are very similar to the Bessel functions.

https://en.wikipedia.org/wiki/Bessel_function#/media/File:Bessel_Functions_(2nd_Kind,_n%3D0,1,2).svg

LikeLike