Re: [Development] Color Management support in Qt 5?
Am 10.11.2013 11:05, schrieb John Layt: On 9 November 2013 12:50, Olivier Goffart oliv...@woboq.com wrote: On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote: I like the idea of re-starting small, and quite a bit of what was done in Nokia times can certainly be re-used. What if Qt started by simply *enabling* color management. I.e. giving access to the information that an application needs to perform color management tasks itself. In a much later iteration Qt could perhaps perform color management operations. Qt should IMHO avoid automatic color management under the hood, especially without providing API to control it. Milestones could be: 1) QImage[Reader] gives access to image color profile. Either whole profile or just an identifier in case of standard spaces such as sRgb. 2) QScreen gives access to the current display color profile for that specific screen. 3) There are notifications (signals?) when the a window changes to another screen, or when a screen profile is changed in the system. 4) Same as 2 but for installed Printers on the system. ... 99) QColorEngine can do color conversions using an input profile, a source Image an output profile plus different parameters. Ideas? Kai-Uwe, what color management feature (or enabler) are you missing most in Qt? Allow me to disagree :-) How usefull are 1-4 without 99? What exactly can you do with that information. Well, I'm no expert at the graphics side of things, but I think before you can start applying a color profile you need to know what color profile to apply :-) If we at least expose that config for apps to use then they only need to apply the transforms themselves, rather than also having to abstract the system config. Then afterwards we can start using the config ourselves in our own code. OTOH we don't want to ship api that we may have to change later when we start using it ourselves in anger. I think step 1 is very definitely a cross-platform api to access the host system config and profiles, regardless of whether we make it public or not. That's easy enough for Windows and Mac where each has a single color management framework built-in, but on Linux we still have two competing systems (perhaps Kai-Uwe can update us on that situation, is there a single combined config yet?). Most applications use for Xorg the ICC Profile in X spec [1]. The spec is served by Oyranos CMS as well as the colord CMS and others. Now, to really expose my lack of knowledge, AFAIK Mac especially and Windows graphics contexts can apply the required transforms themselves internally, so wherever we use the native context it's surely just a case of configuring them to do the work for us? It's really only on Linux or XP that we would have to have code for doing the transforms ourselves using LCMS? But like I said, I know nothing of our graphics internals :-) Lcms is for realtime conversions too slow. OpenGL provides in some profiles a 3D texture lookup on the GPU, which is fast. kind regards Kai-Uwe Behrmann [1] http://www.openicc.info/index.php?title=ICC_Profiles_in_X_Specification_0.4 ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
On Sat, Nov 9, 2013 at 12:50 PM, Olivier Goffart oliv...@woboq.com wrote: Allow me to disagree :-) How usefull are 1-4 without 99? What exactly can you do with that information. I think that in the meantime this has been well reasoned by Kai-Uwe and John: It could be a sane starting point and be needed API for later steps -also from your suggested list-, anyways. Also, I was indeed just thinking about color correcting opaque images and colors. Less about blending, anti-aliasing or gradients. But let's combine our fields, then. 1) QImage[Reader] converts automatically to linear color space, so that all QImage's are in the linear color space A few cents regarding ICC profile usage: How would we do the linearization; by using the image profile to transform the image data (what about alpha channel)? And with which output profile (i.e. to which color space)? Note that there really is no meaningful RGB without Profile/Colorspace, unless we define a linear qtRgb space for that and ship a profile for that with Qt. I believe that Lab would actually be the right intermediate space for what you suggest. blah It is afaik really linear to our eyes, can contain all RGB/CMYK gamuts, and is in the first place a natural intermediate format when transforming from one device space to the other (e.g. from digital camera A to computer screen B). It would therefore make late and early color binding (Kai-Uwe's mail) workflows co-exist peacefully. We would have to consider white point handling, but that's a minor detail. /blah However, all our RGB-based algorithms would have to be re-implemented in Lab, of course minimum 16 bits per channel, which basically already kills my suggetion :p 2) A conversion to the screen's colorspace is done at the end (by the platform plugin? by the compositor?) Definitely a workflow which app developers will want. Especially when using QtWebkit, since now most web browsers can do that. But good question... by whom, on which platform. That's what made push my mile stone to 99. Good discussion, let's keep the ball rolling! ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
On Sunday 10 November 2013 11:05:06 John Layt wrote: On 9 November 2013 12:50, Olivier Goffart oliv...@woboq.com wrote: On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote: I like the idea of re-starting small, and quite a bit of what was done in Nokia times can certainly be re-used. What if Qt started by simply *enabling* color management. I.e. giving access to the information that an application needs to perform color management tasks itself. In a much later iteration Qt could perhaps perform color management operations. Qt should IMHO avoid automatic color management under the hood, especially without providing API to control it. Milestones could be: 1) QImage[Reader] gives access to image color profile. Either whole profile or just an identifier in case of standard spaces such as sRgb. 2) QScreen gives access to the current display color profile for that specific screen. 3) There are notifications (signals?) when the a window changes to another screen, or when a screen profile is changed in the system. 4) Same as 2 but for installed Printers on the system. ... 99) QColorEngine can do color conversions using an input profile, a source Image an output profile plus different parameters. Ideas? Kai-Uwe, what color management feature (or enabler) are you missing most in Qt? Allow me to disagree :-) How usefull are 1-4 without 99? What exactly can you do with that information. Well, I'm no expert at the graphics side of things, but I think before you can start applying a color profile you need to know what color profile to apply :-) If we at least expose that config for apps to use then they only need to apply the transforms themselves, rather than also having to abstract the system config. Then afterwards we can start using the config ourselves in our own code. OTOH we don't want to ship api that we may have to change later when we start using it ourselves in anger. I think step 1 is very definitely a cross-platform api to access the host system config and profiles, regardless of whether we make it public or not. That's easy enough for Windows and Mac where each has a single color management framework built-in, but on Linux we still have two competing systems (perhaps Kai-Uwe can update us on that situation, is there a single combined config yet?). Now, to really expose my lack of knowledge, AFAIK Mac especially and Windows graphics contexts can apply the required transforms themselves internally, so wherever we use the native context it's surely just a case of configuring them to do the work for us? It's really only on Linux or XP that we would have to have code for doing the transforms ourselves using LCMS? But like I said, I know nothing of our graphics internals :-) There is really two uses case: 1) Enabling API so QImage can be used as a container for programs that do proffesional image processing 2) Correctness of the Qt painting system. (Regarding drawing images from the internet, antialiasing, and blending) Enabling a QImage::colorProfile(), having public API for color conversion, or having QImage with more than 32bit per pixel would fit the use case #1 The question we need to ask ourself is if we want to provide such advanced API for image manipulation. Or should the image manipulation software make use of specialized third party libraries or implement it themself. Then we have the IMHO more important thing which is correctness of Qt itself. How can Qt be suitable for an image manipulation program if it does not even draw properly? If you don't know what I mean, here are the problem with the current implementation of the raster paint engine: The raster paint engine assume a linear color space.(I don't what the scene graph does). It assume that the intensity of a pixel is proportional to its value. In other words, it assumes that a pixel (128,128,128) will have half of the intensity of (255,255,255). But because the human eyes is more sensible to low intensity it is common to have a non linear intensity. (This is called gamma) And color profiles usually have different gamma. And every screen have a different gamma too. For example, when drawing a black line with antialiasing enabled, Qt will try to compute what is the portion of a pixel which contains, and if half of the pixel is covered by the line, then the pixel will have 0.5 of the value. But that's only valid in a linar space. Same when blending one image on another one: Qt will do alpha * pixel1 + (1-alpha) * pixel2.Again, one would need to account for the gamma while blending, but Qt Does not. Also the computation used when drawing an image with smooth scale would need to use gamma correction. The difference is not that big but is clearly visible to the trained eyes. Samuel once showed me a demo he made that was showing the difference on a few examples. So this is why I am saying that
Re: [Development] Color Management support in Qt 5?
On 9 November 2013 12:50, Olivier Goffart oliv...@woboq.com wrote: On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote: I like the idea of re-starting small, and quite a bit of what was done in Nokia times can certainly be re-used. What if Qt started by simply *enabling* color management. I.e. giving access to the information that an application needs to perform color management tasks itself. In a much later iteration Qt could perhaps perform color management operations. Qt should IMHO avoid automatic color management under the hood, especially without providing API to control it. Milestones could be: 1) QImage[Reader] gives access to image color profile. Either whole profile or just an identifier in case of standard spaces such as sRgb. 2) QScreen gives access to the current display color profile for that specific screen. 3) There are notifications (signals?) when the a window changes to another screen, or when a screen profile is changed in the system. 4) Same as 2 but for installed Printers on the system. ... 99) QColorEngine can do color conversions using an input profile, a source Image an output profile plus different parameters. Ideas? Kai-Uwe, what color management feature (or enabler) are you missing most in Qt? Allow me to disagree :-) How usefull are 1-4 without 99? What exactly can you do with that information. Well, I'm no expert at the graphics side of things, but I think before you can start applying a color profile you need to know what color profile to apply :-) If we at least expose that config for apps to use then they only need to apply the transforms themselves, rather than also having to abstract the system config. Then afterwards we can start using the config ourselves in our own code. OTOH we don't want to ship api that we may have to change later when we start using it ourselves in anger. I think step 1 is very definitely a cross-platform api to access the host system config and profiles, regardless of whether we make it public or not. That's easy enough for Windows and Mac where each has a single color management framework built-in, but on Linux we still have two competing systems (perhaps Kai-Uwe can update us on that situation, is there a single combined config yet?). Now, to really expose my lack of knowledge, AFAIK Mac especially and Windows graphics contexts can apply the required transforms themselves internally, so wherever we use the native context it's surely just a case of configuring them to do the work for us? It's really only on Linux or XP that we would have to have code for doing the transforms ourselves using LCMS? But like I said, I know nothing of our graphics internals :-) Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote: Allow me jump into this topic to contribute to its liveliness :) The term Color Management has been used in different ways here on the list. Lately, it was about how to blend images in a non-linear color space. That is IMHO perhaps a small and not that typical part of what color management means for imaging applications. I like the idea of re-starting small, and quite a bit of what was done in Nokia times can certainly be re-used. What if Qt started by simply *enabling* color management. I.e. giving access to the information that an application needs to perform color management tasks itself. In a much later iteration Qt could perhaps perform color management operations. Qt should IMHO avoid automatic color management under the hood, especially without providing API to control it. Milestones could be: 1) QImage[Reader] gives access to image color profile. Either whole profile or just an identifier in case of standard spaces such as sRgb. 2) QScreen gives access to the current display color profile for that specific screen. 3) There are notifications (signals?) when the a window changes to another screen, or when a screen profile is changed in the system. 4) Same as 2 but for installed Printers on the system. ... 99) QColorEngine can do color conversions using an input profile, a source Image an output profile plus different parameters. Ideas? Kai-Uwe, what color management feature (or enabler) are you missing most in Qt? Allow me to disagree :-) How usefull are 1-4 without 99? What exactly can you do with that information. All the QPainter API assume linear colorspace (at least in the raster paint engine). And that would be difficult to change that and the result would be much slower painting. What does the scene graph do? That means that when you blend images or smooth scale, or antialias, Qt assume everything is in the linear colorspace. I think milestones could rather be: 1) QImage[Reader] converts automatically to linear color space, so that all QImage's are in the linear color space 2) A conversion to the screen's colorspace is done at the end (by the platform plugin? by the compositor?) 3) Allow QImage to be in any colorspace and have QImage::colorProfile() 4) change QPainter, and graphicssystem to handle different colorspaces. -- Olivier Woboq - Qt services and support - http://woboq.com - http://code.woboq.org ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
Am 09.11.2013 12:50, schrieb Olivier Goffart: On Saturday 09 November 2013 03:02:18 Alessandro Portale wrote: Allow me jump into this topic to contribute to its liveliness :) The term Color Management has been used in different ways here on the list. Lately, it was about how to blend images in a non-linear color space. That is IMHO perhaps a small and not that typical part of what color management means for imaging applications. I like the idea of re-starting small, and quite a bit of what was done in Nokia times can certainly be re-used. What if Qt started by simply *enabling* color management. I.e. giving access to the information that an application needs to perform color management tasks itself. In a much later iteration Qt could perhaps perform color management operations. Qt should IMHO avoid automatic color management under the hood, especially without providing API to control it. Milestones could be: 1) QImage[Reader] gives access to image color profile. Either whole profile or just an identifier in case of standard spaces such as sRgb. 2) QScreen gives access to the current display color profile for that specific screen. 3) There are notifications (signals?) when the a window changes to another screen, or when a screen profile is changed in the system. 4) Same as 2 but for installed Printers on the system. ... 99) QColorEngine can do color conversions using an input profile, a source Image an output profile plus different parameters. Ideas? Kai-Uwe, what color management feature (or enabler) are you missing most in Qt? Allow me to disagree :-) How usefull are 1-4 without 99? What exactly can you do with that information. All the QPainter API assume linear colorspace (at least in the raster paint engine). And that would be difficult to change that and the result would be much slower painting. What does the scene graph do? That means that when you blend images or smooth scale, or antialias, Qt assume everything is in the linear colorspace. I think milestones could rather be: 1) QImage[Reader] converts automatically to linear color space, so that all QImage's are in the linear color space 2) A conversion to the screen's colorspace is done at the end (by the platform plugin? by the compositor?) 3) Allow QImage to be in any colorspace and have QImage::colorProfile() 4) change QPainter, and graphicssystem to handle different colorspaces. Alessandros feature list allows for early binding by applications. That is essentially what colour managed apps do today. They take input colours and convert them to output colours themself. With the mentioned APIs inside Qt, they can do that the Qt way without platform specific code. Oliver, what you describe is about late colour binding. A minor annotation to your point 1) QImage[Reader] converts automatically to linear color space, so that all QImage's are in the linear color space Some app authors will dislike to be forced to have uncontrolled colour conversions. So I would like to add the feature request for a conversion switch off for opaque images. Uncontrolable changes of pixel colours can result in e.g. wrong measurements for ICC profile generation. Otherwise I do not see a contradiction to what Alessandro wrote as his feature list is a precondition to do the automatic or late colour binding stuff. kind regards Kai-Uwe Behrmann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
On Saturday 09 November 2013 12:50:24 Olivier Goffart wrote: I think milestones could rather be: 1) QImage[Reader] converts automatically to linear color space, so that all QImage's are in the linear color space Needs a 48 bit QImage. I remember a proposal to add support for larger bit depths was rejected, but cannot find the reference right now (to check how old the proposal was). Christoph Feck (kdepepo) KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
We created our own platform agnostic image loading and management code outside of Qt due to lack proper support in QImage for non typical texel formats/bit depths. (We support 8bit/16bit/32bit int and 16bit/32bit floating point) It should also be mentioned that on top of the QImage[Reader] code supporting load for these exotic texel types, it's also important to ensure that any kind of texel transformation documents which texel formats it is able to operate in. (eg: if the transformation happens in 8bit int only it will degrade your 16 bit half float texel data during down-conversion for transformation) This is actually a surprisingly common under the hood issue with these kinds of less texel types even in applications such as Adobe Photoshop. (A good way to test is with a large (4k, 8k, etc) test input texture with a unique value for each texel - it's easy to detect after a load/save or non-destructive xform if you have reduced the number of unique values and to what degree) I'd be open to helping out with this in QImage if the feature is a serious candidate for inclusion into Qt. I'd also very much like to see optional support for the kind of formats that support this type of texel data well, such as OpenEXR. Thanks! Chris Gilbert Knald Technologies, LLC On 11/9/2013 5:03 AM, Christoph Feck wrote: On Saturday 09 November 2013 12:50:24 Olivier Goffart wrote: I think milestones could rather be: 1) QImage[Reader] converts automatically to linear color space, so that all QImage's are in the linear color space Needs a 48 bit QImage. I remember a proposal to add support for larger bit depths was rejected, but cannot find the reference right now (to check how old the proposal was). Christoph Feck (kdepepo) KDE Quality Team ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
Am 08.11.2013 14:17, schrieb Sorvig Morten: On 07 Nov 2013, at 12:48, Kai-Uwe Behrmann k...@gmx.de wrote: Detecting a colour space and converting to device colour spaces is around the same amount of developer time as for special casing sRGB. Detecting sRGB among hundrets of ICC profiles is not trivial or fast, while such a detection does not matter in a generic colour managed environment. EXT_texture_sRGB provides only sRGB gamma to linear gamma conversions. That is a thiny bit of grafic processing, which is needed for handling colour space conversions. The spec is clear to not doing anything about dislpaying sRGB images on a monitor. So this OpenGL extension does not help much with colour management. Short term support for sRGB only would make Qt a pretty limiting choice for many colour managed applications. IMHO, limiting support to RGB in a first development stage is a more sound target. Hello! You did not give me much wiggle room with this reply - did you simply want to end the discussion? Oh, I joined the discussion to keep it alive. Sorry, if my reply was perceived in a different mode. For example, the existance of EXT_framebuffer_sRGB supports my argument that limiting support to sRGB will be simpler, but you don’t mention it at all. As I mentioned, the GL extension does no complete colour space conversion as it handles only gamma and not colour primaries. It is intented for memory storage savings, which are unrelated to any colour management concerns. In fact a small shader can do a similar gamma correction. On the other hand a different shader could do as well a full colour space conversion. sRGB is other than for storage not of much value. Nonetheless sRGB is traditionally used as factual blending space. But e.g. wayland devs think seriously around linear gamma blending spaces, which give lesser artefacts. If one plans for mobile only, then a single blending colour space with low bit depth storage might be an option. But I wanted to point out, that this appears to me like a serious regression on desktop. The implications are certainly up to decide by the Qt community. kind regards Kai-Uwe Behrmann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
Allow me jump into this topic to contribute to its liveliness :) The term Color Management has been used in different ways here on the list. Lately, it was about how to blend images in a non-linear color space. That is IMHO perhaps a small and not that typical part of what color management means for imaging applications. I like the idea of re-starting small, and quite a bit of what was done in Nokia times can certainly be re-used. What if Qt started by simply *enabling* color management. I.e. giving access to the information that an application needs to perform color management tasks itself. In a much later iteration Qt could perhaps perform color management operations. Qt should IMHO avoid automatic color management under the hood, especially without providing API to control it. Milestones could be: 1) QImage[Reader] gives access to image color profile. Either whole profile or just an identifier in case of standard spaces such as sRgb. 2) QScreen gives access to the current display color profile for that specific screen. 3) There are notifications (signals?) when the a window changes to another screen, or when a screen profile is changed in the system. 4) Same as 2 but for installed Printers on the system. ... 99) QColorEngine can do color conversions using an input profile, a source Image an output profile plus different parameters. Ideas? Kai-Uwe, what color management feature (or enabler) are you missing most in Qt? Br, Alessandro On Fri, Nov 8, 2013 at 11:53 PM, Kai-Uwe Behrmann k...@gmx.de wrote: Am 08.11.2013 14:17, schrieb Sorvig Morten: On 07 Nov 2013, at 12:48, Kai-Uwe Behrmann k...@gmx.de wrote: Detecting a colour space and converting to device colour spaces is around the same amount of developer time as for special casing sRGB. Detecting sRGB among hundrets of ICC profiles is not trivial or fast, while such a detection does not matter in a generic colour managed environment. EXT_texture_sRGB provides only sRGB gamma to linear gamma conversions. That is a thiny bit of grafic processing, which is needed for handling colour space conversions. The spec is clear to not doing anything about dislpaying sRGB images on a monitor. So this OpenGL extension does not help much with colour management. Short term support for sRGB only would make Qt a pretty limiting choice for many colour managed applications. IMHO, limiting support to RGB in a first development stage is a more sound target. Hello! You did not give me much wiggle room with this reply - did you simply want to end the discussion? Oh, I joined the discussion to keep it alive. Sorry, if my reply was perceived in a different mode. For example, the existance of EXT_framebuffer_sRGB supports my argument that limiting support to sRGB will be simpler, but you don’t mention it at all. As I mentioned, the GL extension does no complete colour space conversion as it handles only gamma and not colour primaries. It is intented for memory storage savings, which are unrelated to any colour management concerns. In fact a small shader can do a similar gamma correction. On the other hand a different shader could do as well a full colour space conversion. sRGB is other than for storage not of much value. Nonetheless sRGB is traditionally used as factual blending space. But e.g. wayland devs think seriously around linear gamma blending spaces, which give lesser artefacts. If one plans for mobile only, then a single blending colour space with low bit depth storage might be an option. But I wanted to point out, that this appears to me like a serious regression on desktop. The implications are certainly up to decide by the Qt community. kind regards Kai-Uwe Behrmann ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
Detecting a colour space and converting to device colour spaces is around the same amount of developer time as for special casing sRGB. Detecting sRGB among hundrets of ICC profiles is not trivial or fast, while such a detection does not matter in a generic colour managed environment. EXT_texture_sRGB provides only sRGB gamma to linear gamma conversions. That is a thiny bit of grafic processing, which is needed for handling colour space conversions. The spec is clear to not doing anything about dislpaying sRGB images on a monitor. So this OpenGL extension does not help much with colour management. Short term support for sRGB only would make Qt a pretty limiting choice for many colour managed applications. IMHO, limiting support to RGB in a first development stage is a more sound target. kind regards Kai-Uwe Behrmann Sorvig Morten morten.sor...@digia.com schrieb: On 06 Nov 2013, at 17:18, Kai-Uwe Behrmann k...@gmx.de wrote: What is the point of special casing sRGB? sRGB is special for a couple of reasons: - Most/Many of the images published for web are in the sRGB color space. - OpenGL has support for sRGB textures and frame buffers. Given that progress has halted on this so far it might be good idea to reduce scope to something that can be completed cross-platform in a reasonable amount time. There are arguments against as well, we don’t want to add API that would limit (future) support to sRGB only for example. Morten _ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
On 04 Nov 2013, at 10:49, John Layt jl...@kde.org wrote: On 4 November 2013 08:22, Sletta Gunnar gunnar.sle...@digia.com wrote: The work that was done is here: https://codereview.qt-project.org/#dashboard,1002033 The work was abandoned after the transition to Digia and the author is no longer in the Qt community, so little has happened since then. Thanks. It's a question that pops up in KDE every now and then, and for printing too, so just thought I'd check. We'll have to continue to work around it for now, but I'll try find if anyone in the color management community wants to take on the task. I believe the most urgent issue is handling sRGB images correctly. Perhaps we can start there and sketch out some possible solutions? Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
What is the point of special casing sRGB? kind regards Kai-Uwe Behrmann Sorvig Morten morten.sor...@digia.com schrieb: On 04 Nov 2013, at 10:49, John Layt jl...@kde.org wrote: On 4 November 2013 08:22, Sletta Gunnar gunnar.sle...@digia.com wrote: The work that was done is here: https://codereview.qt-project.org/#dashboard,1002033 The work was abandoned after the transition to Digia and the author is no longer in the Qt community, so little has happened since then. Thanks. It's a question that pops up in KDE every now and then, and for printing too, so just thought I'd check. We'll have to continue to work around it for now, but I'll try find if anyone in the color management community wants to take on the task. I believe the most urgent issue is handling sRGB images correctly. Perhaps we can start there and sketch out some possible solutions? Morten _ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
On 06 Nov 2013, at 17:18, Kai-Uwe Behrmann k...@gmx.de wrote: What is the point of special casing sRGB? sRGB is special for a couple of reasons: - Most/Many of the images published for web are in the sRGB color space. - OpenGL has support for sRGB textures and frame buffers. Given that progress has halted on this so far it might be good idea to reduce scope to something that can be completed cross-platform in a reasonable amount time. There are arguments against as well, we don’t want to add API that would limit (future) support to sRGB only for example. Morten ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
The work that was done is here: https://codereview.qt-project.org/#dashboard,1002033 The work was abandoned after the transition to Digia and the author is no longer in the Qt community, so little has happened since then. cheers, Gunnar Fra: development-bounces+gunnar.sletta=digia@qt-project.org [development-bounces+gunnar.sletta=digia@qt-project.org] p#229; vegne av Knoll Lars [lars.kn...@digia.com] Sendt: 4. november 2013 01:54 To: John Layt; development@qt-project.org Emne: Re: [Development] Color Management support in Qt 5? Hi John, as far as I know there¹s nobody doing any work on it right now. Cheers, Lars On 02/11/13 14:10, John Layt jl...@kde.org wrote: Hi, I'm wondering if anyone is working on color management support in Qt 5? I know there was some thought about it before 5.0 and vague suggestions about support in 5.1 or 5.2, but I suspect that was lost in the move from Nokia to Digia? Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
Re: [Development] Color Management support in Qt 5?
Hi John, as far as I know there¹s nobody doing any work on it right now. Cheers, Lars On 02/11/13 14:10, John Layt jl...@kde.org wrote: Hi, I'm wondering if anyone is working on color management support in Qt 5? I know there was some thought about it before 5.0 and vague suggestions about support in 5.1 or 5.2, but I suspect that was lost in the move from Nokia to Digia? Cheers! John. ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development ___ Development mailing list Development@qt-project.org http://lists.qt-project.org/mailman/listinfo/development
