Multiple monitors and ICC profiles

[bxf]

Since FPV remembers which monitor it was last used on, it would be logical for it to also remember which ICC profile was used in conjunction with that monitor.

I was using a script to invoke FPV with the desired -m and -icc switches, but if I subsequently invoke FPV directly (by double-clicking on an image) while a the last monitor used if OFF, FPV displays the image on the available monitor, but still using the previous monitor's ICC profile. I've changed my script to save the profile in the Registry (HKCU\Software\ARSD\FastPictureViewer\CustomTargetColorProfile), but I believe this should be handled automatically by FPV.

I trust I'm being coherent:)

Thanks.

[Axel]

FPV has first-class color management with ICC v2 and v4 monitor profile support, as well as support for embedded profiles, but indeed the corner case you describe (your profiled monitor is turned off when you start the program, and FPV displays on your other monitor instead) is not covered.

The obvious fix is to turn the monitor "on" before displaying images

Joke aside the program needs to know the profile in advance and it cannot switch profiles on the fly for various reasons.

On the other hand it successfully color-manages GPU-accelerated display modes, something others currently fail to do (i.e. the Windows built-in slide shows are unmanaged despite Windows Photo Viewer being color-aware).

Our approach lets users specify a color profile to use for occasionally connected devices that are not exactly "monitors", such as LCD projectors, precisely by passing the output device's profile's name through the -icc command-line argument, which overrides the program's default settings.

[Astara]

Joke aside the program needs to know the profile in advance and it cannot switch profiles on the fly for various reasons.

It doesn't sound like he was asking it to change while it was being displayed.

It sounded like he clicked on the file in explorer, and FPV didn't use the color profile for the current monitor. Presumably, FPV uses the color profile for the monitor it is displaying the picture on.

If I display a picture or video on my samsung 51" LED-LCD it would have 1 profile (a bit better suited for video than art/photography or program development) @1920x1080. but displayed on my desktop -- it has a 30% wider color gamut (NTSC/Adobe level) @2560x1600. On Windows 7, it knows which profile goes with which monitor -- so are you saying that FPV won't display images correctly if I use it once on my right monitor and then in a different copy -- display the same image in the left window?

I don't see how that's "dynamic" -- I wouldn't expect it to change an already displayed object (though some programs do, dynamically change the profile based on what monitor they are displaying on, that is the exception more than the rule). But Launching the program and having it open the pictures on 1 monitor should use it's profile vs. if I open the program, and drag it over to the other monitor (because the program opens on my default monitor), -- and now display a picture -- it sounds like it is all but guaranteed to get it wrong?

I mean it's unlikely that if you have two monitors, that you can control which monitor the program comes up on (likely the last monitor used). So if you have to move it to the other monitor, I would hope it would load the correct profile for that monitor.

That HAS to be a dynamic feature, since not doing so would disallow dragging windows -- I'm wouldn't see it as a requirement to change any currently displayed image as you drag it from one monitor to the next, but certainly, if I open the next image on the new monitor, i'd want it to use the correct profile. How else do you change monitors?

[Axel]

The explanation of the current program's design and behavior regarding monitor profiles is pretty clear: the user can optionally configure a monitor profile in the program options. If set, this profile is used to transform pixels sent to the display.

From the above, it is clear that no automatic profile change occurs and since most people tend to have only one calibrated/profiled monitor on which they perform color-critical viewing, supporting one profile set in the options is deemed enough.

Now what if the program is displayed across two monitors, one profiled and one not, or with a different profile? What is the next level of expectations? Use two profiles and paint the left half with one profile and the other half with the other?

The general case is well covered with the current implementation and I have no immediate plans to change this.

Besides that the monitor on which the program starts can be controlled. Please check the FAQ and the available command-line options