I’ve been out of the Mac scene for too long to know what is best these days, but back in the day I always liked Acorn. It’s cheap, relatively simple and easy to learn, and can do most of the things the average person would need to do to with images. The free version of Affinity is probably better (though a lot more complex) these days though.
Regarding whether they compile okay, I wouldn’t be surprised if they are “damaged” to the level they look like in the editor, if one just drags the image straight into the editor. Given how it is stored in the text itself under those conditions, it must conform to RTF specifications, and so quite often that will involve conversion.
Using links, either to the disk or to images in the project, is almost always the way to go. That keeps the image in its original format, and while the preview might look bad, when you compile it will try to use the original as best as it can. It will still run into the above problems though, because a lot of compile involves making an RTF, which really means even linked images ended up embedded briefly, before either saved into that file format, or converted to another.
Off the top of my head, only the Markdown-based, HTML and plain-text formats are ideal for hands-off management of the original images.
I suspect that might be the case, and it’s not the first I’ve heard of HDR image weirdness, where the symptom is bad exposure (probably we’ll see more and more of that since iPhones now save images that way under certain conditions).
It looks like Apple has made some of their tools capable of viewing these properly (dynamically downgrading them to regular displays basically, if a supported HDR monitor is not found), while they haven’t touched their programming toolkit, to add similar capabilities in third-party software. This would be depressingly typical, hence the long tradition of, “…but Pages does X!” you will see around here.