This should be the last beta before the final release! There isn’t a lot that’s changed, which is a good thing. The most important thing to try out is the application of embedded color profiles. Previously, the color profile was loaded* and then included when saving the image*, but now it is loaded, applied to the image, and discarded (you don’t want to double apply the color profile!). You will probably see some JPEG or HEIC images that now load with more saturated (or possibly less saturated) colors; they will match the appearance you see in Explorer thumbnails and previews.
To get this update, make sure you have "Also check for pre-release (beta) versions" enabled in Settings, and then click on the Check Now button.
You can also download it directly by heading over to the forum.
Changes since 4.2 beta build 7116:
- New: Embedded color profiles are now applied when loading images of supported file types (JPEG, PNG, HEIC, etc.). This is a one-time conversion to the sRGB color space that results in the color profile being discarded once it has been applied.
- Fixed: The HEIC file type’s Quality slider is now limited to a maximum value of 90 while Microsoft fixes a heap corruption crash in the codec.
- Fixed: The DIB and RLE extensions will now be registered for APPX (Store) installations
- Fixed: Bicubic resampling in the Move Selected Pixels tool was not correctly handling alpha in some cases. This fix has required a reduction in performance.
- Fixed: Explorer thumbnails for some image types (PDN, DDS, TGA) were not rendering their alpha correctly. You may not see the effect of this fix for a particular image until that image is resaved, or you clear Explorer’s thumbnail cache.
* for supported file types such as JPEG
paint.net blog 
Rick, i’m wondering whether it is sound to apply the color profile upon load and discard it before saving. Unless the color profile is a null operator, it will first introduce a little loss of precision during load because the conversion is executed in higher bit-depths (exceeding 8) but reduces the actual pixels back to the 8-bits which Paint.NET uses during edits. Furthermore, deleting the color profile upon saving the image prevents one to link the source color profile (say a camera?) and the future target profile (say a printer) for a color-calibrated pipe-line. Forcing the written image file and future image-viewer to sRGB implies another loss of precision when outputting to (say) that printer on another computer (that doesn’t run Paint.NET?). I suggest Paint.NET to do nothing with the color profile while loading nor saving, but to pass the profile along into the newly saved image file. Effectively, Paint.NET would then act in the storage-color-space. If you really need to display the image (while editing) with identical color as the explorer thumbnails, then you should apply the color profile during the final blit-to-screen operation. Maybe, it is even better to make this options.
It’s an ambiguous issue, I agree. I suspect most people will not notice, some will see that their images finally match what thumbnails/previewers display, and for others … I can always add an option somewhere to control it.
Images are always reduced (or increased!) to 8-bits per component when loaded into Paint.NET. So applying the color profile doesn’t hurt in that area. The color conversion is, I assume anyway, already performed with the necessary precision by WIC. If necessary I can tell WIC to promote to 64-bits per pixel, do the conversion, then truncate back down to 32-bits per pixel.
I’m not sure what value there is to be doing edits in the wrong color space? You won’t really be able to tell what things actually look like, assuming the color profile does significant enough adjustments.
In addition, Paint.NET isn’t meant to be a “professional” level editor in the same vein as, say, Photoshop or Lightroom. That doesn’t mean it isn’t included in the toolchain by some/many, but expectations are different for it in areas such as precision.
I’ll certainly let feedback guide the direction of this. I’m planning on adding a registry key setting to turn this off for those who really need things to be done that way. If necessary I can then promote it to a checkbox in the Settings UI. Longer term, it will be best to attach the color profile to the Layer, have a button to toggle, delete, or add, and to do the sRGB conversion only in the back-end of the rendering engine.
Do not that I have removed this for the final release of 4.2 (just now). See my italicized notes here: https://blog.getpaint.net/2019/07/13/paint-net-4-2-is-now-available/
Ambiguous indeed. But first off, the per-component precision could accrue to quick significant levels. The most visible difference between the explorer thumbnails and the view in Paint.NET is probably caused by gamma correction (which was originally meant to assign a higher value-resolution to darker pixels upon storage). Different cameras use different gamma values for storage. Different displays and printers use different gamma values for their outputs. That is part of the reason why those pesky color profiles exist at all. So gamma is connected to precision… yeah confusing. Secondly, some file formats support only a limited set of color-spaces (sRGB, linear-RGB, HSL, CIE XYZ, YCbCr, et cetera) of which some are solely meant to improve the image compression ratio.
And on top of that, you quickly start thinking of DTP scenarios. For instance: it is simple when working with single images, but what does it mean to blend together two photographs from different cameras having different color-spaces (say RGB and CIE XYZ) and different gamma values (ergo: different color profiles)? Your initial proposal (loading the image while applying and discarding the embedded color profile) is indeed the easiest solution in that you silently adopt a working-color-space (linear-RGB?), which then should also be set when writing the image file. And that means: while editing in linear-RGB space, you don’t have enough value-precision for the dark colors, but you do have correct blending between layers! Scenarios right… Your proposed long-term solution to not apply the color profile upon loading but keeping it with each layer, is indeed better and avoids losing precision and definition due to conversion from storage-color-space to working-color-space (the original storage-color-space would essentially be your layer-working-color-space), and you won’t loose much precision if you choose a blending-color-space with high bit-depth (say 16 bits-per-channel linear RGB) during the blending operations. Note that you will suffer a draw-performance drop due to those per-layer-conversions with every draw operation, although that can be remedied partly be pre-blending all layers above and all layers below the current layer (for which you incur a memory cost); it is never free right? Two final points of concern: a) could users ignore or understand that different image layers have different working-color-spaces, and b) How about dealing with copy-paste operations across image layers?
Sounds like the best solution for now is what I’ve already got, and extending it. Always convert to sRGB (by applying the color profile), whether loading a file or pasting from the clipboard. Going much further requires a ton of research and engineering, but going backwards results in inappropriate blending that doesn’t take color profiles into account.
Understandable; the-term solution shall be exactly that.
But remind the future you: the ton of research you mentioned will point out that the layer-blending in your original and current proposal may have been acceptable now, but still is off the mark for ‘correct rendering’.
Well, if everything is in sRGB space, then blending should be fine with respect to that and it’s just a precision issue.
It’s also not clear to me what it would mean to run an effect, like say Gaussian Blur, on the “uncorrected” pixel data in a layer that has a color profile attached to it. It clearly won’t produce the right outcome, although that’s technically what’s happening now but without the correct sRGB output to the screen.
Upgrading the precision of the layer compositor can be done without affecting a lot of other things. The big big big work item is upgrading the front end (the layer storage itself) to be tiled and to be able to use non-BGRA32 formats. That will be pretty cool when that happens.
Hmmm, I’m not sure about linear blending in sRGB color space. The color sciences define an XYZ- and associated Yxy color space which are definitely linear with the amount of light that enters the eye. Transforming between the sRGB and XYZ color spaces (https://en.wikipedia.org/wiki/SRGB#The_reverse_transformation) involves two steps: 1) a gamma function including an optional discrete step, and 2) a linear 3×3 transformation matrix. I have been referring to the linear-RGB space before, which sits between steps 1 and 2. Now, when ‘blending’ in the graphics sciences is defined in curved color space*, by all means do blend in sRGB. Otherwise, perform the blending in linear-RGB (or XYZ) or you will implicitly curve the outcome of the involved sums and multiplications.
*) as far as I know, graphics blending originated in the foto lightroom laboratories of the olden days in which actual light was mixed and films were used as masks for lighting yet other films (https://en.wikipedia.org/wiki/Dodging_and_burning). Therefore, I guess, blending should be executed in linear-RGB color-space.
Then again, when all other softwares blend in sRGB, please do stick to the established rule.