(NB, I have made quite a few assumptions here. If your question is actually about something else altogether then I think it needs clarification).
Assuming that
you are using the Windows desktop version of Word
you are actually trying to merge the images and not the paths to
the images
{ MERGEFIELD Picture } contains the full path to the image, either
with forward slashes or doubled-up backslashes, e.g.
G:/test/2020090801 includepicture/img003.jpg
or
G:\\test\\2020090801 includepicture\\img003.jpg
then you should be able to do this, but the field coding is a bit weird.
The field coding that I believe would work in most circumstances is as follows, where all the {} are the special field code brace pairs that you can insert using ctrl-F9
{ IF "{ MERGEFIELD Picture }" <> "{ MERGEFIELD PrimaryPicture }" "{ IF { INCLUDEPICTURE "{ IF THINGY { MERGEFIELD Picture } }" } { INCLUDEPICTURE "{ IF THINGY { MERGEFIELD Picture } }" }" }
If you merge to a printer, or merge to email using the HTML format, that should work.
I you merge that to a new document using Word 365/2016/2019 and possibly 2013, initially it appears as if the field codes have all been replaced by the correct pictures. However, if you then save the output, close it, and re-open it, I believe you will actually see that you are left with an INCLUDEPICTURE field with an * MERGEFORMATINET option at the end (It's supposed to preserve picture size on replacement).
If you merge to email using attachments, the attachment will be like the saved document. That is, when the recipient opens the attachment, the user may see the pictures (which should be correct) or they may see the field code with the *MERGEFORMATINET. The problem is that the file name in the INCLUDEPICTURE field may be a file name in the file system on the computer performing the merge, or even if it is at a public Internet (say http://) address, the recipient may not have access to it. So if they then select those INCLUDEPICTURE fields and press F9, they may end up with a picture border with a red cross and error message in it. Better to try to get them to select the fields and press ctrl-shift-F9 to "unlink" them, i.e. replacing them by their existing result (the image).
If you don't use this rather silly-looking construction, what tends to happen is that the merge result shows the same picture for every record in the data source. That means that a merge to print can't work, a merge to HTML email probably won't work, and with a merge to a new document, the user will always have to select and re-execute (F9) the INCLUDEPICTURE fields to get the right pictures. A merge to email attachments works rather like a merge to a new document, so in that case the user would need to update the fields in the attachment they receive. But if the pictures were on the hard disk in the machine performing the merge, they won't have them and they'll just see an outline with a red cross and error message.
If you look around the Internet, you will probably find a number of places where this approach is described, but unfortunately, people seem to have one of two experiences. Some people experience the above. Others seem to end up with completely unlinked field codes and do not have to worry about the ctrl-shift-F9 thing. I do not know why this is so. It could be a configuration issue, but I think it is more likely that something changed in Word 2013 or 2016.
Incidentally, I believe that if you use this style of coding, even path names with single backslashes, e.g.
G:\test\2020090801 includepicture\img003.jpg
are processed correctly. However, ISTR that there are some limitations on path length (perhaps a 255 character total path length) and that UNC path names may cause problems even if you double up all the backslashes.
As I mentioned, this is a pretty weird piece of field coding. Normally an IF field looks something like this:
{ IF operand1 operator operand2 "result-if-true" "optional result-if-false" }
e.g
{ IF { x } = 1 "some text" }
but in this case we have
{ IF { INCLUDEPICTURE something } { INCLUDEPICTURE something } }
which doesn't actually fit any of Word's normal IF field patterns at all. Nor does { INCLUDEPICTURE something } generate any kind of "TRUE" result. It just seems to have to be there.
Even the nested code
{ IF THINGY { MERGEFIELD Picture } }
doesn't follow the IF-field syntax pattern. Elsewhere you will see this written as
{ IF TRUE { MERGEFIELD Picture } }
which makes it look as if it fits the pattern
{ IF condition "result-if-true" }
but in fact you can use any old word (more or less) instead of TRUE. Even FALSE. What you don't seem to be able to do is just use the rather more obvious
{ MERGEFIELD Picture }
on its own. I use THINGY to try to make it clear that there isn't a typical Word logical expression there.
In the situation where you do not need an IF statement to decide whether or not to insert an image, you can use the much simpler construction
{ INCLUDEPICTURE "{ IF THINGY { MERGEFIELD Picture } }" }
Again, without the "IF THINGY" part, the merge tends to insert the same image for every record in the data source.
There is another way to insert images without nesting them inside an IF field, which is (broadly speaking) to do it this way:
{ INCLUDEPICTURE "{ IF "{ MERGEFIELD Picture }" <> "{ MERGEFIELD PrimaryPicture }" "{ MERGEFIELD Picture }" "<the path+file name of a 1-pixel picture>" } }
However, you probably need to add in some of the { IF THINGY } stuff to make that work properly too, and I haven't tested it recently.
