Pretty shitty of Intel to not support it on previous generations.

Calibrate, no, but you can profile the display. Probably not necessary though, and the apps for profiling weren’t very good last I checked. In my experience the IPad displays shift very little over time. Like, I had to recheck the results on a one and a half year old IPad Pro, because I couldn’t believe it. Almost no change whatsoever.

The apps on the Ipad should be color managed so the P3 display is not the problem.

What display do you have and how have you calibrated and profiled it?

Do you have true tone turned off on the Ipad?

Have you matched brightness and are you comparing them under the same viewing conditions?

Yes, that would be one concern. As long as you stay in color managed applications there’s no need to limit the gamut, and that larger gamut can be useful when working with photos (or the rare occasion when some content is in a larger gamut).

Limiting the gamut would only make sense in non-color managed applications. However, a lot of applications are color managed (important to know which ones though) and in cases where you want accuracy you can use a LUT to map the source color space to your display. For example if you work with video in Resolve or somesuch, or for video playback or games.

I reckon switching between calibrations and profiles are a bigger pain that trying to stick to color managed apps, and using LUT’s where desired or necessary.

It should also be mentioned that the SRGB mode in most consumer displays is utter trash. They tend to be locked down with the brightness set way too high, as well as poorly calibrated.

Of course that’s not an issue on displays that support hardware calibration.

There’s a third option as well, but it’s a bit more complicated to setup.

You could calibrate and profile the display (in this case you want to generate corrections for vcgt), then create a synthetic profiles with your displays white point and primaries, as well as your target gamma. Create a 3DLUT with the synthetic profile as source, and your display profile as destination.

If you want to limit the gamut you can use your display’s white point and rec. 709 primaries for the synth profile.

Plug the synth profile into your OS color management. Then load the 3DLUT with DWMLut.

This is sort of like doing hardware calibration, but in software… or something like that. It’s an option for displays that lack hardware calibration capabilities.

I use this approach myself. It is best with fairly well behaved displays that are not too far off of your target.

My setup is such that I target P3-D65 with gamma 2.4. The display is close to P3 gamut so it works. I have a second LUT for rec. 709 that I can switch to for grading video.

This way I’m pretty well set for switching between apps like Resolve, Blender and Photoshop. Basically, I can live in gamma 2.4 when I want to and ICC color managed apps only have to make a simple gamma 2.4 to gamma 2.2 transform. This also reduces banding.

I’m not sure I would recommend this for OP as I think he needs to get the basics of color management down first.

I would mostly agree, however…

Calibrating to sRGB is a pretty bad idea for photographic work. In the motion picture and VFX world you would calibrate to rec. 709 or whatever standard you’re targeting, but that is mostly down to how the color management pipelines work. You don’t get ICC based color management there, and there aren’t that many different outputs.

For photographic work you can have a ton of different outputs, as every printer, ink and paper combination has it’s own color space. For that purpose, it’s best to keep the display at it’s native gamut as a wider gamut allows you to see more of the colors you’re working with.

A good and simple strategy is to try and target a D65 white point and 2.2 gamma. That is by adjusting the RGB “gain” in the display and finding the gamma setting that is closest to 2.2. Don’t write anything to the video card gamma table - that will just lead to banding (which you’ll get anyway, so best to minimize it).

Then, you simply profile the display and make sure to install the profile in your OS. This will take care of things in (ICC) color managed applications. Meaning, output transforms will be handled on the fly to match the display.

For non-color managed applications, well… it’s probably easiest to try and avoid them. Windows UI will look oversaturated and games don’t support ICC color management. There are ways to use LUT’s for this if it bothers you. In fact, you might actually want to get madVR and use a LUT for your video player, if you like to watch videos on your computer. Most web browsers work fine if you stick to gamma 2.2. With Firefox you can enable color management and plug in your display profile.

Anyhow, as for proofing… there’s nothing inherently wrong with it, but I find it unnecessary for web delivery. You could use it as a quick preview of what happens to your image after color space conversion. I rarely bother.

Start with raw conversion to a large working color space, and make sure camera raw (or whatever raw converter you use) is set to 16 bits. Prophoto RGB is good.

Make your edits and then convert it to sRGB, or whatever you want. Edit -> convert to profile in Photoshop. If you’re targeting print, proof to the printers profile. Don’t convert, as the printer software will handle the conversion.

I answer in kind and don’t mince words.

Oh, so you know all about my wants and needs?

Congratulations, you know how to use Docker. I prefer not to deal with nested containers and configure things myself.

Being a FOSS-tard comes with an inability to understand criticism of software because it’s free (if you don’t value your time).

You obviously can’t handle a simple question of better alternatives than software that shits the bed, and judging by your response you’re deep in FOSS-tardedness.

And, no, expecting software to work, have sane configurations and clear documentation is not being entitled. It means valuing your time.

Presuming I don’t know how or care to configure things is laughable.

So, tell, what user error breaks the auto download window in Deluge web UI?

Known bug, by the way.

You sound like a FOSS-tard. Are you a FOSS-tard?

Poor design and bugs make bad software. I’m limited in both time and patience, which is why I’m asking for software that ain’t shit. Simple as that. If not wanting to deal with poorly functioning software makes me entitled, then yeah…

Hm, butthurt much?

I’ve already mentioned it other comments. It’s running in an Arch VM. Purging it and reinstalling does not restore config files. According to one person here the configs are not only stored in ~/.config as the documentation says. On top of that, error messages for torrents are not shown in the UI, but in the log file - with a level of logging that is most undesirable.

Maybe you like spending hours getting shit software to work, but I don’t.

Looks like a pain to setup, and rutorrent looks like it’s straight from the 90’s (and not in a good way).