I have been using MPV as an image viewer for the past 6 months, and all I can say is, I am impressed. It is lightweight, loads images quickly, even navigation between images in the same folder is super fast (does it do buffering?). Moreover, it opens any image format, including WebP.
It is better than any image viewer out there currently.
I propose these changes:
mpv.conf:
[image]
autofit-larger=80%x80%
force-window=yes
hr-seek=yes
image-display-duration=inf
input-conf=~/.config/mpv/image-input.conf
loop-playlist=inf
loop-file=inf
mute=yes
reset-on-next-file=mute,video-pan-x,video-pan-y,video-zoom
script=/usr/share/mpv/lua/autoload.lua
image-input.conf:
1 repeatable playlist-prev
2 repeatable playlist-next
3 set mute no
` cycle video-unscaled
ENTER cycle pause
DOWN seek -2
UP seek 2
LEFT repeatable playlist-prev
RIGHT repeatable playlist-next
MOUSE_BTN3 add video-zoom 0.1
MOUSE_BTN4 add video-zoom -0.1
MOUSE_BTN7 add ao-volume -5
MOUSE_BTN8 add ao-volume 5
SPACE repeatable playlist-next
TAB set video-zoom 0 ; set video-pan-x 0 ; set video-pan-y 0
a repeatable add video-pan-x 0.05
d repeatable add video-pan-x -0.05
s repeatable add video-pan-y -0.05
w repeatable add video-pan-y 0.05
q seek -1
e seek 1
I disagree. mpv isn't a great image viewer, because opening images that are larger than the texture size supported by the GPU makes it fail.
These are some things where mpv fails as image viewer:
Having a (light) default profile for images would probably not be that off, though.
I'm also using it as an image viewer. It works fine, but having some of the features wm4 mentioned (especially prefetching and not having to resort to bad hacks to get a gallery view) would be great.
OP, you might like this collection of scripts: https://github.com/occivink/mpv-image-viewer (and https://github.com/occivink/mpv-gallery-view too).
For me, it loads images so fast, I thought it was doing prefetching. Scrolling through my phone photo collection (12 megapixels) is almost instantaneous, compared to the default Gnome image viewer, which takes around 1 second.
I have also tried to load few very high resolution photos (30 megapixels), and it opens them. How big would the image have to be to exceed the texture size? Maybe relying on CPU decoding for large images is okay.
I have also tried to load few very high resolution photos (30 megapixels), and it opens them. How big would the image have to be to exceed the texture size? Maybe relying on CPU decoding for large images is okay.
that depends on you GPU, something about max texture size. for vulkaninfo it would be maxImageDimension2D (here 16384) for example i believe. the CPU already decodes it, what is important is presentation.
For me, it loads images so fast, I thought it was doing prefetching.
Remote directories.
Even though I do not recommend to use it as an image viewer.
However, I think you could consider about the third-party program which is based on libmpv ------- qimgv
(It doesn't support the color profile) https://github.com/easymodo/qimgv/issues/89
I think that uses mpv only for video, the rest uses Qt's framework.
PS: I think mpv supports embedded icc profiles now, but not sure if used by default.
Only if you have a display ICC profile set.
On Thu, 13 Aug 2020 08:41:21 -0700, wm4 notifications@github.com wrote:
PS: I think mpv supports embedded icc profiles now, but not sure if used by default.
--
You are receiving this because you are subscribed to this thread.
Reply to this email directly or view it on GitHub:
https://github.com/mpv-player/mpv/issues/7983#issuecomment-673552628Non-text part: text/html
mpv uses the file extension (or mimetype, if available) to identify picture files. According to my experience, this does not always give the correct result.
I actually did not even know (or think about) using mpv as an image viewer. Based on this, I somewhat agree with strelec.
Perhaps a disclaimer can be added to denote the main limitations when it comes to limits for mpv here, but as the example of strelec shows, when mpv is better at viewing images than designated image viewers, it's quite a quality comment to make.
mpv uses the file extension (or mimetype, if available) to identify picture files. According to my experience, this does not always give the correct result.
That's only partially true. It relies on ffmpeg probing, but falls back to guessing by file extension, which actually happens at least for jpg at least in some cases.
Anyway, some of these problems would be solvable for sure with some effort (incremental loading), others (displaying multiple images at once) would be extremely awkward to fit into the CLI player. The latter would ironically be relatively easily to achieve with libmpv.
And just as I wrote this, I found/fixed another image format detection problem. FFmpeg is to blame.
Don't know about Linux but all image viewers on Windows are pretty subpar. I'd say that HoneyView comes close to being the best but it lacks proper upscaling and has a few other annoying issues.
So in the meantime I switched to mpv and use it as a manga reader. I'm way too lazy to look into profiling so I just have a separate instance of mpv for images. It works well for the most part when combined with some minor config tweaks like no-osc and save-on-quit, and these scripts:
https://github.com/occivink/mpv-image-viewer
https://github.com/Dudemanguy/mpv-manga-reader
The only issue I've encountered so far is mpv being unable to parse contents of some archives on Windows properly, displaying file names as mpv_unknown#321 instead of image321.jpg for example. But as was pointed out in another discussion this is probably an issue with libarchive's locale/encoding handling on Windows.
With all that said, I support this idea if that's something contributors are willing to consider in the future. Obviously I don't expect mpv to evolve into a full-fledged image viewer but some improvements to image handling would be nice to have.
There is another issue whith using mpv as a image viewer which is that the player does not rotate pictures according to the orientation exif infos. FFmpeg is liable for that: https://trac.ffmpeg.org/ticket/6945. Unfortunately, no fix is coming.
As we have no idea when FFmpeg will be able to insert the right orientation filters when reading pictures, would it be possible to make mpv detect the exif infos and rotate pictures if needed ? I understand that the risk is to forget to remove the patch the day FFmpeg processes images correctly. Maybe a script, provided by default with mpv, could do the job ?
Here is the code (Python) I use to overcome this issue, if it can help (based on https://www.media.mit.edu/pia/Research/deepview/exif.html):
def _jpeg_exif_orientation(uri):
f = None
try:
if r'://' in uri:
f = _open_url(uri, 'GET')
else:
f = open(uri, 'rb')
if f.read(2) != b'\xff\xd8':
f.close()
return
t = f.read(2)
if t == b'\xff\xe0':
len = struct.unpack('!H', f.read(2))[0]
f.read(len - 2)
t = f.read(2)
if t != b'\xff\xe1':
f.close()
return None
len = struct.unpack('!H', f.read(2))[0]
if f.read(6) != b'Exif\x00\x00':
f.close()
return None
ba = {b'MM': '>', b'II': '<'}.get(f.read(2),'')
if ba == '':
f.close()
return None
if f.read(2) != (b'\x00\x2a' if ba == '>' else b'\x2a\x00') :
f.close()
return None
f.read(struct.unpack(ba + 'I', f.read(4))[0] - 8)
ne = struct.unpack(ba + 'H', f.read(2))[0]
for i in range(ne):
e = f.read(12)
if struct.unpack(ba + 'H', e[0:2])[0] == 0x0112:
nb = {1: 1, 3: 2, 4:4}.get(struct.unpack(ba + 'H', e[2:4])[0],0)
if nb == 0 or struct.unpack(ba + 'I', e[4:8])[0] != 1:
f.close()
return None
f.close()
return {1: 'upper-left', 3: 'lower-right', 6: 'upper-right', 8: 'lower-left'}.get(struct.unpack(ba + {1: 'B', 2: 'H', 4: 'I'}[nb], e[8:8+nb])[0], None)
f.close()
return None
except:
if f:
try:
f.close()
except:
pass
return None
Rotation = {'upper-left': 0, 'lower-right': 180, 'upper-right': 90, 'lower-left': 270}.get(_jpeg_exif_orientation(URI), 0)
send_command(('set_property', 'video-rotate', Rotation))
Well, we could add a jpg "demuxer" to mpv, since ffmpeg is failing in many other aspects here (such as probing), and has been behaving badly and causing trouble for years.
@PCigales commented on Sep 18, 2020, 1:17 PM GMT+4:30:
There is another issue whith using mpv as a image viewer which is that the player does not rotate pictures according to the orientation exif infos. FFmpeg is liable for that: trac.ffmpeg.org/ticket/6945. Unfortunately, no fix is coming.
Can't you just contribute the fix to ffmpeg?
@ghost commented on Aug 23, 2020, 2:33 PM GMT+4:30:
Anyway, some of these problems would be solvable for sure with some effort (incremental loading), others (displaying multiple images at once) would be extremely awkward to fit into the CLI player. The latter would ironically be relatively easily to achieve with libmpv.
Why would the CLI player have any problems? It just displays the logs and gets the input. We can just output logs similar to the plugin autoload:
Image displayed: ...
Image displayed: ...
Image displayed: ...
PS: I, too, have not found any usable image viewers for macOS.
To activate the image profile automatically:
[extension.jpg]
profile=image
[extension.png]
profile=image
[extension.jpeg]
profile=image
[extension.webp]
profile=image
[extension.gif]
profile=image
[extension.psd]
profile=image
There are two bugs though:
PS: I, too, have not found any usable image viewers for macOS.
You may try XnviewMP (mac version).
mpv seems to ignore embedded ICC profiles (in particular, for PNG files) and thus displays images completely wrong unless they happen to be in usual sRGB colorspace.
Are there any possible workarounds for this? or is it simply not implemented in mpv?
Also, if anyone knows a good alternative for Windows which can act like a good image viewer and has a true fullscreen mode, please share.
I don't know where to ask anymore. Everyone on Web seems to recommend IrfanView, but it also doesn't properly support embedded ICC profiles.
I don't know where to ask anymore. Everyone on Web seems to recommend IrfanView, but it also doesn't properly support embedded ICC profiles.
You may try XnviewMP/Faststone.
I just saw https://github.com/seenaburns/isolate. Might be interesting for people here.
Are there any possible workarounds for this? or is it simply not implemented in mpv?
When color management is enabled, mpv respects embedded ICC profiles passed as AVFrame sidedata (type AV_FRAME_DATA_ICC_PROFILE). A quick grep through lavc confirms that pngdec, mjpegdec, webp and tiff set this side data.
That being said, mpv currently still ignores embedded ICC profiles when color management is disabled. Most likely you need to set some ICC profile (--icc-profile option) to make it work.
Thanks @haasn !
I think it makes sense to enable it by default too, with some generic sRGB profile (which is what's normally used anyway if there is no particular ICC profile chosen for the monitor, right?) to match color conversion behavior of applications such as Firefox and Chromium (color management always enabled; if display profile is not set, assume it's sRGB).
mpv became my favorite image viewer too; I shared my image viewing config at https://sr.ht/~guidocella/mpv-image-config
And mpv already has a prefetch-playlist option. It noticeably speeds up going to the next file even with local large images for me, and I can see that going back to the previous one is slower because of no prefetching.