It is still RGB but it will display many more colors. There is a new monitor type called HDR monitor. Comparing it to my solution, creating a QImageIOPlugin can cause program coupling to be a little serious and reduce the scalability. Load the raw image data using OpenCV or something elseīut, simply developing a QImageIOPlugin is good enough.The more general way in my imagination is to change the image loading logic to: Will Nomacs treats normal jpeg and jpeg contains color profiles as different image type?) If I developed a QImageIOPlugin, how do Nomacs decide when to use my plugin and when use the QT's built-in? (e.g. But it is better to give users some warning like 'You are saving a picture as RGB color space, while the source is CYMK'. Since it is not focusing on editing, converting everything to RGB is reasonable. Oh, I see your opinion Nomacs is an image viewer. I prefer a more general way to solve the color management problem because it is not a problem caused by a specific image container. (OpenCV have this support but Nomacs use QImage everywhere) Giving such images write support is not a good idea before Nomacs gain native support for these color spaces. So converting color space for these images will use some lossy algorithm, which is impossible to revert. Some color space such as HDR color spaces have the ability to present a color which cannot be presented by sRGB.Does this method need to create a QImageIOPlugin for every image container? In the future, there may be more and more image format supports different color spaces.Making such a QImageIOPlugin will break the write support. These image format is currently supported by nomacs, some of them with write support. HEIF has support for using a standard color space beside RGB. As far as I know, jpg&tiff (maybe more) has support for embedded color profile.Give me some time to get familiar with QImageIOPlugin. Would you be interested in developing such a plugin? I could support you to some extent (given limited time resources). Advantage of a Qt plugin would be that other Qt based programs would benefit as well. A good sample is the HEIF Plugin which we use for loading heif/heic files because it also wraps around an existing loading library. In general, it's best to develop a QImageIOPlugin. again: heavy dependency, more work to implement.as you said, we solve a bunch of loading issues.This could also be solved using a plugin. so there are basically two options you named left:Īdvantage: little extra dependencies, probably straight forward to implement. We can use OpenCV to open the image, then use LittleCMS to convert it.Īnother solution: Is it possible to make a plugin called 'ImageMagick image opener' that open images using ImageMagick then convert it to QImage using a 'correct way'? This will not add new dependencies to the main program.įrom my point of view, we don't want magick dependency in the main repo due to portability. It has a lot of implementations such as ImageMagick and GraphicsMagick.įor a lightweight dependency, LittleCMS can be a good choice. Magick can be considered as an interface. (OpenCV is somehow a bit library, right?) So, I believe it is reasonable that an 'Image Viewer/Editor' have such a dependency.It can quickly solve all feature requests like 'Please add support for xxx image format'. It can handle massive amounts of image format and support more options when saving an image (compared to Qt).It focused on image processing, which can be regarded as a supplement to OpenCV. But, it does have so many useful features.It contains so many compile options to enable its functionally. Using magick is not too good (new dependency)

OpenCV is focused on computer vision (CV), but color management is not CV.

Nomacs folder viewer