2 Replies Latest reply on Sep 21, 2011 11:47 PM by Vit Novak

    ACR ignoring SensorFormatFactor in lens profile

    Vit Novak Level 3

      A while ago, i made a raw lens profile for my compact camera SX110, by editing a file manually, with a text editor. It worked well until sevral days ago, when de-vignetting and distortion correction was suddenly boosted by a factor about 10x for the photos from the last trip

       

      It turned out that a reason for that was different values of exif tags focal plane x resolution and focal plane y resolution in dng files, caused by different resolution of jpg choosen in the camera. Checking those dngs with exiftool shown me that exiftool is using these tags for calculating the crop value (because tags like focal plane x size and focal plane y size are missing in these dng files). It seems to be the same with ACR. If I delete those tags, two things happen:

       

      - exiftool not showing the crop factor (which is wrongly calculated anyway)

      - ACR profile not correcting vigneting, distortion and CA of that dng, without any message that something is wrong with dng or lens profile

       

      So, it seems that ACR is actually ignoring SensorFormatFactor, specified in the profile. Instead of that, it is using tags from raw file - if they exist ... which doesn't make any sense to me ...

      I can understand that I can't expect ACR to work flawlessly with unsupported camera ... however I can't understand why ACR is ignoring tags from the profile

       

      Any comment on this from Adobe team ?

        • 1. Re: ACR ignoring SensorFormatFactor in lens profile
          MadManChan2000 Adobe Employee

          Hi Vit,

           

          To apply the physical lens profile model to an image, ACR needs to know the physical pixel size of the image. In most cases, ACR does this by looking for available EXIF metadata (prefers FocalPlane*Resolution tag, but also uses combo of FocalLength and FocalLengthIn35mm if necessary). For some cameras, ACR has an internal lookup table to deal with known bad metadata cases (e.g., I've seen some compact models with bogus metadata values, such as claiming they have 12-micron pixels, which is ... not right). But for the most part, the calculation of the pixel size is done from metadata.

           

          The SFF data in the profile refers to the source data (i.e., the size of the image circle represented by the lens), rather than the destination image to which the profile is applied.  This is because for interchangeable lens systems (e.g., SLR), the lens may be for 35 mm format whereas the destination image may be smaller format (e.g., APS-C). 

           

          In your case, where the metadata describing the pixel size of the destination image is not available, ACR/LR should fall back to using the SFF as described in the profile.  That is, ACR/LR assumes that the physical image circle size described in the lens profile exactly matches that of the target image.  But it sounds like that's not happening in your case, and I don't know why.  If you can provide me with a sample image and corresponding profile, I can investigate (you have my email addr, I believe).

           

          Eric

          • 2. Re: ACR ignoring SensorFormatFactor in lens profile
            Vit Novak Level 3

            Hi, Eric, thanks for the quick answer

             

            Yes, in the meantime I studied this stuff a bit further and concluded that reading the crop factor from raw metadata instead from the profile is indeed the right way, for the reason you specified (interchangeable lens systems)

             

            So in my case I obviously have to correct those metadata (and rescale the profile parameters accordingly)

             

            In case you want to investigate why ACR don't read SFF from the profile if FocalPlane*Resolution tags are missing, I'm sending you test dngs. One with those tags and one with those tags removed, and the lens profile (which was, however, tuned to wrong crop factor of about 3.7 because of wrong metadata in the dng). However, I think it's not necessary to bother with this, unless you think it is important