If data format X can be stored on a UNIX block device, then it can also be stored in a file. [But see nasty details below]. "Image file" is a short, generic name for this. I.e. it is a sequence of bytes that might be copied to or from a block device. If you want to, you can call it different things depending on what you use it for.
"Image file" might mean a disk image... or the image might technically be of a format used on a disc... there are more details about this case below. It might also be a format that can be used on a disk partition. It might also be a filesystem. Which we might call a "filesystem image".
An LVM Logical Volume is another type of block device.
I think the most significant distinction is whether it is a filesystem image or not. If it is a filesystem image, it is a single filesystem that you can mount with mount -oloop.
A complete "disk image" might not be a filesystem image - e.g. if it was a copy of an internal hard disk. But it might - e.g. if it was a copy of a floppy disk. But you might also be able to copy this filesystem image to a partition of an internal disk. Therefore I find "disk image" ambiguous, and not really more specific than "image file".
[Note] You do not mention "host-managed SMR" devices. These impose additional restrictions. Filesystems that were only designed for standard disks do not work within these restrictions. I will not mention them further.
[Nasty details] Ancient devices may also have provided a few numbers to specify the "geometry"; typically the size of a sector, a track, and a cylinder. These were used to optimize data layout on ancient slow disks.
So far, so good. And modern filesystem layouts may be optimized to align them with stripe size of a RAID device.
But a data format used on a disk could also assume that you already know what these numbers are... So if you only have an image of the disk, then you might have difficulties reading the data format. There can be problems with this for the MBR partition table format. There are some more horror stories in the obsolete Large Disk HOWTO.
Modern uses of MBR, and also GPT partition tables, do not use C/H/S geometry. However they still require that you know the sector size! Historically most disks have used 512 byte sectors. So most software will try this sector size when reading an image file. Then if the partitions were created for a disk which reports 4KB sectors, you will have a problem!
Perhaps surprisingly, this means that if USB sticks ever start reporting 4KB sector sizes, it will not be possible to use them for current Linux installer images!
(The legacy Apple format thoughtfully includes both the sector size and the number of sectors. As is mentioned in this story).
Filesystems tend not to have this problem. If you write a filesystem which uses 512 byte blocks to a device which uses 4KB sectors... The superblock will most likely store the block size used. However it is likely the filesystem code will refuse to work, if the block size is smaller than the device sector size.
Some software has attempted to guess the "geometry". For example older versions of fdisk, used to try to guess the C/H/S geometry from existing partitions.
CD-Rs and DVD-Rs use a different sector size: 2048 bytes.
dd if=/dev/zero bs=1M count=100 >fs.img; lo=$(losetup --show --find fs.img); mkfs -t ext4 $lo; mkdir /mnt/lo; mount $lo /mnt/lo. I'm not sure how there's really any difference between "an image file for a filesystem" and "an image file for a partition or logical volume". It's an image file. – Chris Davies Mar 01 '19 at 22:05