I have encountered this problem in the past, and have just encountered it again using 10.5.1.) I finally decided to give it a good hard look and try to understand it. I believe I can explain what is going on, and I have a kludge to get around it.
Cutting to the chase for those who want the kludge:
1. Add the image to the MXD.
2. Add any single arbitrary georeferencing point to the link table.
3. Georeferencing > Update Georeferencing
4. Remove the image from the MXD.
5. Delete the aux.xml file associated with the image.
6. Add the image. (It will pop in at a somewhat different location.)
7. Georeference as usual.
(This slightly messes up my workflow, as I normally Build Pyramids and Statistics for all images, and deleting the aux.xml file deletes the statistics, but these can be built later.)
OBSERVATIONS AND EXPLANATION:
In my current project, I am working in NAD 1983 BC Albers (WKID 102190), which has a linear unit of meters. Choosing one of my problem images and using ImageMagick identify, the TIFF has tags (among others): Geometry=16853x10772+0+0, Resolution=300x300, units=PixelsPerInch, Print size=56.1767x35.9067", Orientation=TopLeft.
When I insert a problem image and mouse over the approximate top left and bottom right corners the projected location reads as approximately 0,36 and 56,0 meters. (The image is inserted into the MXD with no projection information. However, when it is inserted it still needs to be mapped to some location in the CRS [i.e, to zoom to the image it cannot be outside the space mapped by the CRS]. The mapping apparently is transforming 300 pixels per inch to 300 pixels per meter, hence 0,36 and 56,0, ballpark original image locations in inches.)
If I georeference points close to these corners to known locations, the coordinate pairs in the link table are:
1.351994 34.575973 952183.094839 856847.715658
51.362419 1.250201 1034479.259431 801983.605930
(As it happens, the second pair in each case are absolute, known coordinates that are provided by snapping to a grid.)
When I update the georeferencing the TIFF file size increases by around 170KB. Arc is writing something to it. Whatever it is is not seen in the tags ImageMagick reads -- they look exactly the same. However, something in that 170KB makes Arc add the image in a different location, where the approximate corners are 0,0 and 56,-36 meters. Presumably this is the correct location, trusting that Orientation=TopLeft means that 0,0 should be the top left corner and that Arc is ignoring that the mapping should be pixels per inch instead of pixels per meter. If I georeference this with the two corners my coordinate pairs in the link table are:
0.937064 -0.727514 952183.094839 911711.825387
50.812487 -34.239148 1034479.259431 856847.715658
And that works fine. (Of course, I'm simplifying and using only two points when I'd normally use more.)
I note that looking at the (incorrect) first aux.xml and (correct) second aux.xml that they have different values for <XOrigin>, <YOrigin>, and <XYScale>.
I'd be happy if ESRI would look into this. The details above should be enough for a programmer to determine why images are being added apparently using the wrong corner as the origin.
