Talk:Proposal for Monitor Profiling

Very interesting article. I have some questions/comments.

1. One of the areas of the lprof "rough" monitor profiler that definitely needs improvement is giving users better ways to find/set a fairly accurate white point for their monitors. There is actually an open tracker item in the sourceforge lprof tracker, #1299386, about this. I think that at the very least the basic approach outlined here could form the basis for using a digital camera as a "poor mans" white point meter. I would like to explore this more as I think this aspect of the experiment is very promising. I should also add that I think that this could also form a basis for helping users evaluate the quality of the lighting in their viewing environment which is an often over looked but very important element in a properly color managed environment. If this approach should prove useful then the solution to #1299386 might consist of documentation of the technique.

2. The article talks about using xgamma or tkgamma for getting the monitor gamma close to a known value (presumably 2.2). Another option is monica which, like lprof, now uses the Norman Koren gamma charts to help set gamma. These charts are a huge improvement over the methods used by most gamma setting tools. Norman claims that these charts allow consistent setting of gamma to a tolerance of +- 0.1. My own experience indicates that this is a very conservative claim and I think that actual tolerance number is closer to +-0.05. Therefore, if a user is going to use one of these tools to set monitor gamma I would highly recommend monica.

3. One limitation/problem with using tools like xgamma, tkgamma or monica is that these have limited usefulness for multi-monitor setups that use one video card. Since in most cases it is only possible to alter the gamma of one monitor and I don't know of any setup that allows for gamma to be set for each monitor independently when using a single video card on Linux workstations and in some cases this also applies to Windows. I don't know if this is an issue on OS/X.

4. I am not sure that I agree with the workflow used to create the camera profile. Specifically that you color corrected the target image before creating the profile. Doesn't this in affect introduce a color cast into the profile? Shouldn't you let the profile remove color casts caused by the camera both for setting the monitor white point and for capturing the monitor profiling target screen image?

Also you don't need to blur the image to fight sensor noise as lprof averages the data in the template "hot spot" areas. Lprof also does some other statistical calculations on this data to help decide how good the data is. Blurring the image does not improve the average value obtained but it will give lprof an incorrect indication of the quality of the image data since it will impact things like the median and standard deviation of the data.

5. Would it not be easier to use lprof to directly apply the camera profile and convert the RGB values to xyz? On the lprof Preferences tab you can select how the target values are handled. One option is "XYZ - Pick from image and apply input profile". By setting the Input profile on that tab to the camera profile and selecting the above option lprof will pick the raw RGB values from the image, then apply the camera profile to these values and then output XYZ data. So I am wondering why you chose to do the conversion using icctrans and a shell script instead of using that functionality built into lprof.

6. One apparent short coming of this technique was that the darker parts of the profile were not correct. This you attributed to camera sensor noise. Yet camera sensor noise should have also been a factor in the image used to create the camera profile and should more or less be canceled out by the profile. I think that possibly a much more significant factor is the amount and type of ambient light in the room at the time the IT8.7 screen image was captured. Even light from the monitor reflected from light colored walls in an otherwise totally dark room could have a significant affect on the darker parts of the resulting profile. I am wondering if you could give more details about how you captured the IT8.7 screen image as I believe that this is critical for this technique to even have a chance of working.

Also perhaps #4 above was a factor in the color casts in the darker parts of the profile.

7. You said that the ProfileChecker in lprof 1.11 crashes. Is this still true for for newer versions of lprof such as 1.11.3.1? If so could you give me more details about exactly how to recreate this so that I can fix it? Or better yet open a bug report in the lprof Bugs tracker.

8. When you used the ProfileChecker to get the gamma, white point and primaries how close were those gamma numbers to what you get in the lprof rough monitor profiler gamma screen?

9. The lprof project is definitely looking into integrating measurement devices into lprof. However, there are only 4 vendors with products in this area and I have been in contact with all of them. Two of them are about to merge and the other two have very limited offerings. Only two have even responded to my inquiries and one of these has said flat out that they will not support Linux. So only one of these vendors has expressed even a little interest in making their products available to Linux/Unix/BSD users. Although some progress has been made with one vendor I am only slightly hopefull that this will be possible in the near future as that progress has been painfully slow. At this point I think that the process is only at about the 10% point and I have already almost given up several times.

Even if instrument support should happen sometime soon I think there is a need to also have "poor man" methods that yield acceptable results for those users that can't afford one of these devices and your experiment could provide the basis for some of these techniques.

Thanks for your work in this area.