There are several ways how you could model this, let me give you some ideas:
Add system field NodeCustomData to the form (of the linked type). NodeCustomData is stored per location in the tree as opposite to DocumentCustomData which is shared by links. Then create custom form control which will provide editing of this value for the given parent. Use node.NodeCustomData["SomeName"] to store that information, differentiation by parent will be done automatically for you, you can optionally use visibility condition, e.g. NodeLinkedNodeID > 0 to completely hide this field from original. This would probably be easiest and most upgrade-proof for smaller to mid-size projects. If your project is under 10k pages in total, I wouldn't hesitate and used this one. For more, it may be wise to run some load tests and review caching.
Model these "links" using Custom tables or Module classes, and provide custom form control to manage them on parent type. This may be little more complicated to do, but would provide most scalability. I would use it for large projects (where your total page count would exceed 50k pages). You may also need to provide custom data source to display this data on live site.
In v9, you can also use the new field type Related pages on the parent type, and add images through it. These are modeled through relationships and you can then use field RelationshipCustomData to store extra information. Scalability in this case would be good, there is a native support for displaying related pages, but you would have to either customize the existing form control (not upgrade-proof) or make a customized copy of it to provide editing interface for the extra information.
Hope this helps.