Thread: [Lcms-user] Anouncement - LPROF-1.11.3 Developemnt Snapshot Released
An ICC-based CMM for color management
Brought to you by:
mm2
From: Hal V. E. <hv...@as...> - 2006-02-21 19:54:14
|
I'm pleased to announce that development snapshot version 1.11.3 of LPROF is now available. This is the sixth development snapshot of the work that has been underway since LPROF became a SourceForge project. Please see the LPROF SourceForge home page at http://lprof.sourceforge.net/ for details. This is a development snap shot of what will become version 1.12 when it is stable. Although testing by the development team indicates that this snapshot appears to be stable it is a development release and as such it should not be considered a stable release. It has not been extensively tested and may have significant unknown bugs. This is being made available so that users can test the new release and report problems and make suggestions for improvements. Significant changes since the last development snapshot include: 1. LPROF now uses the ArgyllCMS spline regression code for creating camera and scanner profiles. Profiles created with the new regression code have both lower delta E numbers and smoother CLUT curves. Users have control of two parameters used by the regression algorithm to tune the resulting profiles. I would like to thank Gerhard Fuernkranz for integrating this into LPROF. 2. LPROF now uses the QT QSetting API to manage user and application settings. On Windows systems settings are now stored in the registry. On Mac OS/X QSettings uses the Carbon preferences API and on Unix/Linux/BSD systems the settings are stored in a text file in the $HOME/.lprof/config directory. Users who have been using previous 1.11.x snapshots will loose whatever settings had been stored in the old configuration file. As a result users will need to reinstall target reference files in LPROF. 3. LPROF now has expanded the the number of items that are actively tracked in the settings/configuration system to include configuration details of all profiles created in LPROF. This will allow users to open a profile that was created with LPROF and all settings in affect at the time the profile was created will automatically become the current settings in LPROF. This includes opening IT8.7 image files and the placing of corner marks on the IT8.7 image. 4. The charts for setting monitor gamma in the rough monitor profiler now work correctly on both little endian and big endian hardware. I would like to thank Oleksandr (Alex) Moskalenko for his assistance in getting the fixes tested for big endian hardware. 5. LPROF now uses VIGRA for all image file IO and has eliminated the need for TiffIO to handle tiff files. LPROF now supports the following image file formats: "BMP" - Microsoft Windows bitmap image file. "GIF" - CompuServe graphics interchange format; 8-bit color. "JPEG" - Joint Photographic Experts Group JFIF format; compressed 24-bit color (only available if libjpeg is installed). "PNG" - Portable Network Graphic (only available if libpng is installed). "PNM" - Portable anymap. "PPM" - Portable pixmap format (color). "SUN" - SUN Rasterfile. "TIFF" - Tagged Image File Format. (only available if libtiff is installed.) "VIFF" - Khoros Visualization image file. With 8, 16 or 32 bit integer or 32 or 64 bit floating point values per color channel if these higher bit depths are supported by the image file format. 8 and 16 bit integer and 32 bit floating point per channel image files have been tested and are working correctly. 32 bit integer and 64 bit floating point per channel images have not been tested at this time but should work. If anyone has the ability to test the untested formats please let the project team know your results. 6. Numerous other smaller bug fixes, enhancements and documentation improvements. The development team has discovered that QT version 3.3.5 has a bug that will prevent LPROF or any application that uses custom QT widgets from building. This normally results in error messages about missing header files during the build process. The files incorrectly listed as missing are: it8selector.h it8fileselector.h iccprofileselector.h Please see http://www.trolltech.com/developer/tasktracker.html?method=entry&id=85440 for more details about the bug and possible fixes. If you receive messages like this while building LPROF please verify your QT version before opening a bug report. Please feel free to download, build, install and test this development snapshot. User feedback is very much appreciated and any reported problems will receive prompt attention from the LPROF development team. In addition, LPROF could use your help in other ways and we are looking for volunteers to handle various tasks. For example, the LPROF team would really like to have someone work on getting the Windows and/or Max OS/X SCons builds working correctly and there are many other areas where we could use additional help. Many of the things that need to be done are non-technical so even those that do not have a technical back ground can contribute. Please contact me if you would like to get involved in this effort in any way. Hal V. Engel |
From: Cory P. <pap...@ju...> - 2006-02-22 13:00:53
|
I got the dev release yesterday and fried it up. A few things I've noticed that seem to be related to the new .lprof prefs structure. I removed the old directory to be sure, but I've found: - 'measurements' directory not automatically created 28.404669 28.412451 27.887160 -> 7.400000 -0.890000 -0.250000 26.147860 26.498054 26.735409 -> 4.770000 0.110000 -2.910000 *************************************** cp: cannot create regular file `/home/papenfuss/.lprof/measurements/test.icc.cgt': No such file or directory - After creating that directory manually, the "Create Profile" button was greyed out sometimes. It would took a trip into "Profile Parameters" (not changing anything) to make it come back and allow profile generation - Trying to run through the resulting profile through "Profile checker" aborted the program with: 32.719844 32.735409 32.377432 -> 11.670000 -0.720000 -0.170000 30.431907 30.571984 29.758755 -> 9.330000 -1.000000 0.320000 28.494163 28.505837 27.949416 -> 7.400000 -0.890000 -0.250000 26.202335 26.533074 26.750973 -> 4.770000 0.110000 -2.910000 ************************************** lcms: Error #12288; File '' not found I can provide version numbers of relevant libraries if necessary. On the plus side, it *did* generate a useable profile. It's significantly more accurate with a larger gamut than the non-local convergence Huge profile from before. Great progress! -Cory On Tue, 21 Feb 2006, Hal V. Engel wrote: > I'm pleased to announce that development snapshot version 1.11.3 of LPROF is > now available. This is the sixth development snapshot of the work that has > been underway since LPROF became a SourceForge project. Please see the > LPROF SourceForge home page at http://lprof.sourceforge.net/ for details. > > This is a development snap shot of what will become version 1.12 when it is > stable. Although testing by the development team indicates that this > snapshot appears to be stable it is a development release and as such it > should not be considered a stable release. It has not been extensively > tested and may have significant unknown bugs. This is being made available > so that users can test the new release and report problems and make > suggestions for improvements. > > Significant changes since the last development snapshot include: > > 1. LPROF now uses the ArgyllCMS spline regression code for creating camera and > scanner profiles. Profiles created with the new regression code have both > lower delta E numbers and smoother CLUT curves. Users have control of two > parameters used by the regression algorithm to tune the resulting profiles. > I would like to thank Gerhard Fuernkranz for integrating this into LPROF. > > 2. LPROF now uses the QT QSetting API to manage user and application settings. > On Windows systems settings are now stored in the registry. On Mac OS/X > QSettings uses the Carbon preferences API and on Unix/Linux/BSD systems the > settings are stored in a text file in the $HOME/.lprof/config directory. > Users who have been using previous 1.11.x snapshots will loose whatever > settings had been stored in the old configuration file. As a result users > will need to reinstall target reference files in LPROF. > > 3. LPROF now has expanded the the number of items that are actively tracked in > the settings/configuration system to include configuration details of all > profiles created in LPROF. This will allow users to open a profile that was > created with LPROF and all settings in affect at the time the profile was > created will automatically become the current settings in LPROF. This > includes opening IT8.7 image files and the placing of corner marks on the > IT8.7 image. > > 4. The charts for setting monitor gamma in the rough monitor profiler now work > correctly on both little endian and big endian hardware. I would like to > thank Oleksandr (Alex) Moskalenko for his assistance in getting the fixes > tested for big endian hardware. > > 5. LPROF now uses VIGRA for all image file IO and has eliminated the need for > TiffIO to handle tiff files. LPROF now supports the following image file > formats: > > "BMP" - Microsoft Windows bitmap image file. > "GIF" - CompuServe graphics interchange format; 8-bit color. > "JPEG" - Joint Photographic Experts Group JFIF format; compressed 24-bit color > (only available if libjpeg is installed). > "PNG" - Portable Network Graphic (only available if libpng is installed). > "PNM" - Portable anymap. > "PPM" - Portable pixmap format (color). > "SUN" - SUN Rasterfile. > "TIFF" - Tagged Image File Format. (only available if libtiff is installed.) > "VIFF" - Khoros Visualization image file. > > With 8, 16 or 32 bit integer or 32 or 64 bit floating point values per color > channel if these higher bit depths are supported by the image file format. 8 > and 16 bit integer and 32 bit floating point per channel image files have > been tested and are working correctly. 32 bit integer and 64 bit floating > point per channel images have not been tested at this time but should work. > If anyone has the ability to test the untested formats please let the project > team know your results. > > 6. Numerous other smaller bug fixes, enhancements and documentation > improvements. > > The development team has discovered that QT version 3.3.5 has a bug that will > prevent LPROF or any application that uses custom QT widgets from building. > This normally results in error messages about missing header files during the > build process. The files incorrectly listed as missing are: > > it8selector.h > it8fileselector.h > iccprofileselector.h > > Please see > http://www.trolltech.com/developer/tasktracker.html?method=entry&id=85440 for > more details about the bug and possible fixes. If you receive messages like > this while building LPROF please verify your QT version before opening a bug > report. > > Please feel free to download, build, install and test this development > snapshot. User feedback is very much appreciated and any reported problems > will receive prompt attention from the LPROF development team. In addition, > LPROF could use your help in other ways and we are looking for volunteers to > handle various tasks. For example, the LPROF team would really like to have > someone work on getting the Windows and/or Max OS/X SCons builds working > correctly and there are many other areas where we could use additional help. > Many of the things that need to be done are non-technical so even those that > do not have a technical back ground can contribute. Please contact me if you > would like to get involved in this effort in any way. > > Hal V. Engel > > > ------------------------------------------------------- > This SF.net email is sponsored by: Splunk Inc. Do you grep through log files > for problems? Stop! Download the new AJAX search engine that makes > searching your log files as easy as surfing the web. DOWNLOAD SPLUNK! > http://sel.as-us.falkag.net/sel?cmd=lnk&kid=103432&bid=230486&dat=121642 > _______________________________________________ > Lcms-user mailing list > Lcm...@li... > https://lists.sourceforge.net/lists/listinfo/lcms-user > -- ************************************************************************* * Cory Papenfuss * * Electrical Engineering candidate Ph.D. graduate student * * Virginia Polytechnic Institute and State University * ************************************************************************* |
From: Hal V. E. <hv...@as...> - 2006-02-22 19:36:48
|
On Wednesday 22 February 2006 05:00 am, Cory Papenfuss wrote: > I got the dev release yesterday and fried it up. A few things > I've noticed that seem to be related to the new .lprof prefs structure. I > removed the old directory to be sure, but I've found: > > - 'measurements' directory not automatically created > 28.404669 28.412451 27.887160 -> 7.400000 -0.890000 -0.250000 > 26.147860 26.498054 26.735409 -> 4.770000 0.110000 -2.910000 > *************************************** > cp: cannot create regular file > `/home/papenfuss/.lprof/measurements/test.icc.cgt': No such file or > directory Found the bug. Not even sure how it even compiled. A new tarball (1.11.3.1) with the fixed (and tested) code is now on sourceforge. > > - After creating that directory manually, the "Create Profile" button was > greyed out sometimes. It would took a trip into "Profile Parameters" (not > changing anything) to make it come back and allow profile generation There might be a path through the code that misses the check to change the state of this button. What would help me is for you to describe the exact steps/conditions when this happens which might not be easy since it does not appear to happen in most cases. That would make it easier for me to reproduce and also give me some clues about were to look. I will also do some testing to see if I can find where this is happening. The new settings code affected how this works and I probably over looked something. > > - Trying to run through the resulting profile through "Profile checker" > aborted the program with: > > 32.719844 32.735409 32.377432 -> 11.670000 -0.720000 -0.170000 > 30.431907 30.571984 29.758755 -> 9.330000 -1.000000 0.320000 > 28.494163 28.505837 27.949416 -> 7.400000 -0.890000 -0.250000 > 26.202335 26.533074 26.750973 -> 4.770000 0.110000 -2.910000 > ************************************** > lcms: Error #12288; File '' not found Again like the above could you describe the exact sequence of steps you went through for this to occur. Does the Profile Checker dialog open? Does this error happen when you press the Inspect Profile button? If the dialog opens what values do you have for Profile: Target: and Measurement: ? And do these appear to be valid to you? > > I can provide version numbers of relevant libraries if necessary. > I don't think this has anything to do with specific version of libraries. As long as lcms is fairly recent. I have been testing with 1.14 and have tested with 1.13 in the past. But I have not tested yet with 1.15. > > On the plus side, it *did* generate a useable profile. It's significantly > more accurate with a larger gamut than the non-local convergence Huge > profile from before. Great progress! > The new profiles should be way better than those created with the old non-local convergence algorithm in every respect. Larger gamut, much lower delta E numbers and smoother CLUT curves. These new profiles will have about the same gamut as the old local convergence algorithm but with slightly better delta E numbers and way smoother CLUT curves. Getting the CLUT curves smooth was the main point of the new algorithm but on the whole it has improved every aspect of these profiles. In addition it runs faster than the local convergence algorithm. At this point I personally believe that the new algorithm is generating profiles that are as good as anything out there even the multi-thousand dollar "professional" commercial profilers. Hal |
From: Cory P. <pap...@ju...> - 2006-02-22 20:14:36
|
> A new tarball (1.11.3.1) with the fixed (and tested) code is now on > sourceforge. > Found, compiled, installed. measurement directory problem solved. >> >> - After creating that directory manually, the "Create Profile" button was >> greyed out sometimes. It would took a trip into "Profile Parameters" (not >> changing anything) to make it come back and allow profile generation > > There might be a path through the code that misses the check to change the > state of this button. What would help me is for you to describe the exact > steps/conditions when this happens which might not be easy since it does not > appear to happen in most cases. That would make it easier for me to > reproduce and also give me some clues about were to look. I will also do > some testing to see if I can find where this is happening. The new settings > code affected how this works and I probably over looked something. > It appears to not become active until Profile Identification is opened at least once. I loaded the image, selected the corners, chose an output icc filename, and then the button became active when I went in Profile Identification... even though I hit cancel. >> >> - Trying to run through the resulting profile through "Profile checker" >> aborted the program with: >> >> 32.719844 32.735409 32.377432 -> 11.670000 -0.720000 -0.170000 >> 30.431907 30.571984 29.758755 -> 9.330000 -1.000000 0.320000 >> 28.494163 28.505837 27.949416 -> 7.400000 -0.890000 -0.250000 >> 26.202335 26.533074 26.750973 -> 4.770000 0.110000 -2.910000 >> ************************************** >> lcms: Error #12288; File '' not found > > Again like the above could you describe the exact sequence of steps you went > through for this to occur. Does the Profile Checker dialog open? Does this > error happen when you press the Inspect Profile button? If the dialog opens > what values do you have for Profile: Target: and Measurement: ? And do these > appear to be valid to you? > Profile checker opens. Hitting Inspect Profile is when it aborts. Profile has the one just generated (/home/papenfuss/.color/icc/test2.icc) Target contains the Q60 file from the Kodak batch of my target Measurement has the .cgt file (/home/papenfuss/.lprof/temp/meaurement.cgt) > > I don't think this has anything to do with specific version of libraries. As > long as lcms is fairly recent. I have been testing with 1.14 and have tested > with 1.13 in the past. But I have not tested yet with 1.15. > I am running 1.15. > > The new profiles should be way better than those created with the old > non-local convergence algorithm in every respect. Larger gamut, much lower > delta E numbers and smoother CLUT curves. These new profiles will have about > the same gamut as the old local convergence algorithm but with slightly > better delta E numbers and way smoother CLUT curves. Getting the CLUT curves > smooth was the main point of the new algorithm but on the whole it has > improved every aspect of these profiles. In addition it runs faster than the > local convergence algorithm. At this point I personally believe that the new > algorithm is generating profiles that are as good as anything out there even > the multi-thousand dollar "professional" commercial profilers. > > Hal Yes... way better, and without the numerical weirdness of the local convergence. I've now only got a couple of patches that have perceivable dE in iccexamin, and they're probably due to a glare on my test shot. No more low-luminance progressive errors. I'm a little curious as to what the two new "knobs" to tweak the spline fit do. I've so far left them at default. -Cory -- ************************************************************************* * Cory Papenfuss * * Electrical Engineering candidate Ph.D. graduate student * * Virginia Polytechnic Institute and State University * ************************************************************************* |
From: Gerhard F. <nos...@gm...> - 2006-02-22 21:16:11
|
Cory Papenfuss wrote: > Yes... way better, and without the numerical weirdness of the > local convergence. I've now only got a couple of patches that have > perceivable dE in iccexamin, and they're probably due to a glare on my > test shot. No more low-luminance progressive errors. I'm a little > curious as to what the two new "knobs" to tweak the spline fit do. > I've so far left them at default. The sliders contol the trade-off between fitting error and smoothness. Moving them up, will increase smoothness, but also the fitting error. The two sliders correspond to the -r<avgdev> and -rs<smooth> options of the Argyll CMS' profile command (see http://argyllcms.com/doc/profile.html), with the exception that lprof's Avgdev = <avgdev> / 100. Both sliders map to a single smoothness/error trade-off metric internally, so they are basically redundant, but have a different scale. I think that one of the sliders will be obsoleted eventually. People usually tend to desire highly accurate profiles, and mostly measure the accuracy simply by comparing the profile to the same data set that was used to create the profile (that's alo what happens if you open the profile checker window after creating the profile). This is IMO mathematically not well-founded. First, even a perfect fit to the measurements used to create the profile does not imply that the profile would fit as well for a different data set. Second, measurements are never error-free, but always (sometimes more, sometimes less) noisy. If you create a profile from measurements which have a random error (noise) of say 2dE average, and if the profile fits this data set with say 0.3 dE average, then it is IMO very likely, that the profile is not really as accurate as it seems; it rather fits the noise in the data, instead of describing the avarage behaviour of the device more accurately. Given such noisy measurements, a smoother profile with a larger fitting error may actually describe the average behaviour of the device more accurately, than an supposedly accurate profile, with a low fitting error. Regards, Gerhard |
From: Cory P. <pap...@ju...> - 2006-02-22 21:39:30
|
On Wed, 22 Feb 2006, Gerhard Fuernkranz wrote: > Cory Papenfuss wrote: >> Yes... way better, and without the numerical weirdness of the local >> convergence. I've now only got a couple of patches that have perceivable >> dE in iccexamin, and they're probably due to a glare on my test shot. No >> more low-luminance progressive errors. I'm a little curious as to what the >> two new "knobs" to tweak the spline fit do. I've so far left them at >> default. > The sliders contol the trade-off between fitting error and smoothness. Moving > them up, will increase smoothness, but also the fitting error. > > The two sliders correspond to the -r<avgdev> and -rs<smooth> options of the > Argyll CMS' profile command (see http://argyllcms.com/doc/profile.html), with > the exception that lprof's Avgdev = <avgdev> / 100. > > Both sliders map to a single smoothness/error trade-off metric internally, so > they are basically redundant, but have a different scale. I think that one of > the sliders will be obsoleted eventually. > Thanks for the info. The only parameter that I played with in argyll that appeared to affect the output was was the -a flag. > People usually tend to desire highly accurate profiles, and mostly measure > the accuracy simply by comparing the profile to the same data set that was > used to create the profile (that's alo what happens if you open the profile > checker window after creating the profile). This is IMO mathematically not > well-founded. First, even a perfect fit to the measurements used to create > the profile does not imply that the profile would fit as well for a different > data set. Second, measurements are never error-free, but always (sometimes > more, sometimes less) noisy. If you create a profile from measurements which > have a random error (noise) of say 2dE average, and if the profile fits this > data set with say 0.3 dE average, then it is IMO very likely, that the > profile is not really as accurate as it seems; it rather fits the noise in > the data, instead of describing the avarage behaviour of the device more > accurately. Given such noisy measurements, a smoother profile with a larger > fitting error may actually describe the average behaviour of the device more > accurately, than an supposedly accurate profile, with a low fitting error. > > Regards, > Gerhard > Interesting thought. Especially since the gamut of the fit color space is much wider than what is measureable from the target. It's impressive how much larger the space is than the target, so if you've got a "super-accurate" fit to the data, it could well be goofy outside. Just a thought about the noise. I know that the whole Bayer thing throws a wrench in the works, but maybe some median filtering rather than simple averaging? I suspect that it's mostly evident at the low-levels where SNR is lower. That's where the pixels that are "hot" matter most. -Cory -- ************************************************************************* * Cory Papenfuss * * Electrical Engineering candidate Ph.D. graduate student * * Virginia Polytechnic Institute and State University * ************************************************************************* |
From: Gerhard F. <nos...@gm...> - 2006-02-24 00:07:10
|
Cory Papenfuss wrote: > Interesting thought. Especially since the gamut of the fit color space > is much wider than what is measureable from the target. It's > impressive how much larger the space is than the target, so if you've > got a "super-accurate" fit to the data, it could well be goofy outside. Yes, in RGB device space, the target covers only a subset of the RGB cube. Only the colors within this subset can be reasonably characterized, using the target as reference, everything outside needs to be extrapolated. Argyll's smoothing splines extrapolate pretty smoothly, so the result should be quite pleasing, but you can't expect a really accurate mapping in the extrapolated areas. However, even though the complete RGB cube is eventually mapped by the extrapolation to CIELAB space, there may exist RGB combinations which are never ever returned by the camera at all - i.e. not the complete extrapolated space is necessarily utilized by the camera. > Just a thought about the noise. I know that the whole Bayer thing > throws a wrench in the works, but maybe some median filtering rather > than simple averaging? At least the noise filters used in cameras seem to perform rather median filtering (or even more sophisticated methods like e.g. http://www.fmrib.ox.ac.uk/~steve/susan/susan/node18.html). Depending on the amount of filtering done, this results in the typical look with homogenous, clean areas (-> loss of details), in those areas where the level differences are small, but nevertheless sharp edges where the level makes a larger jump. On the other hand, the basic task of the Bayer interpolation is rather not noise filtering, but the reconstruction of the original image from subsampled color planes which have only a quarter of the resolution of the original image (or half resolution for green). According to the sampling theorem, only a blurred, band-limited image could be reconstructed from each subsampled color plane. However, that's not satisfactory. Thus more sophisticated algorithms attempt to use the correlation between the color planes, some additional a priori knowledge about typical images, some heuristics, maximum likelihood methods, etc. in order to reconstruct the image at the full resolution. > I suspect that it's mostly evident at the low-levels where SNR is > lower. That's where the pixels that are "hot" matter most. Basically the noise floor is always the limiting factor for the dynamic range that can be captured by a camera/scanner. The resolution of the ADCs is usually chosen in a way, such that one LSB falls below the noise level, such that not the ADC resolution, but still the noise remains eventually the limiting factor. Btw, when I talked about errors I basically mentioned noise, but there are other sources of error as well, including systematic errors, like uneven lighting or vignetting. The latter apply in particular to camera profiling. Even allegedly good shots of a target still often turn out to be not completely homogeneously illuminated - you open the image in an image editor and find with the color picker spatial differences of serveral RGB units on the grey IT8 border (though the image looks visually homogenous). I'm currently also investigating a compensation for uneven illumination, using a lighting model based on one or several point sources which are assumed to illuminate the target, and whose individual positions and intensities are being estimated by optimization. Regards, Gerhard |
From: Hal V. E. <hv...@as...> - 2006-02-22 21:22:16
|
On Wednesday 22 February 2006 12:14 pm, Cory Papenfuss wrote: snip > > It appears to not become active until Profile Identification is > opened at least once. I loaded the image, selected the corners, chose an > output icc filename, and then the button became active when I went in > Profile Identification... even though I hit cancel. OK this helps a lot. It appears to be happening only the first time a profile is created after a new installation. I should be able to find and fix this without too much difficultly. Thanks snip > Profile checker opens. Hitting Inspect Profile is when it aborts. > Profile has the one just generated (/home/papenfuss/.color/icc/test2.icc) > Target contains the Q60 file from the Kodak batch of my target > Measurement has the .cgt file (/home/papenfuss/.lprof/temp/meaurement.cgt) This all looks OK and it appears that the correct data is being passed to the profile checker. So it is not a problem in the interface between the main dialog and the profile checker. > > > I don't think this has anything to do with specific version of libraries. > > As long as lcms is fairly recent. I have been testing with 1.14 and > > have tested with 1.13 in the past. But I have not tested yet with 1.15. > > I am running 1.15. I have not tested with version 1.15 yet so maybe this is a problem with it. I will test this to see if that is the case. Hal |
From: Hal V. E. <hv...@as...> - 2006-02-23 00:30:16
|
On Wednesday 22 February 2006 12:14 pm, Cory Papenfuss wrote: snip > It appears to not become active until Profile Identification is > opened at least once. I loaded the image, selected the corners, chose an > output icc filename, and then the button became active when I went in > Profile Identification... even though I hit cancel. The problem with the Create Profile button being gray or not being gray when it should not be is fixed in CVS. I actually found and fixed to problems related to this. snip > Profile checker opens. Hitting Inspect Profile is when it aborts. > Profile has the one just generated (/home/papenfuss/.color/icc/test2.icc) > Target contains the Q60 file from the Kodak batch of my target > Measurement has the .cgt file (/home/papenfuss/.lprof/temp/meaurement.cgt) > > > I don't think this has anything to do with specific version of libraries. > > As long as lcms is fairly recent. I have been testing with 1.14 and > > have tested with 1.13 in the past. But I have not tested yet with 1.15. > > I am running 1.15. I just did some testing with lcms 1.15 and I was not able to reproduce this particular problem. But LPROF, at least on my machine, had other much more significant problems with 1.15 as the profiles generated were very bad. The profiles had very high delta E numbers (52 average and a peak of 124.5). With 1.14 installed the same setup produced a profile with an average delta E of 1.08 and a peak that is 5.76. I am wondering if there might be some problem somewhere in the lcms code when running on an amd64 machine? I un-installed and reinstalled each version several times to make sure that the only difference was the version of lcms. Anyone have any ideas about what might be going on? Hal |
From: Gerhard F. <nos...@gm...> - 2006-02-23 01:01:38
|
Hal V. Engel wrote: > I just did some testing with lcms 1.15 and I was not able to reproduce this > particular problem. But LPROF, at least on my machine, had other much more > significant problems with 1.15 as the profiles generated were very bad. The > profiles had very high delta E numbers (52 average and a peak of 124.5). > With 1.14 installed the same setup produced a profile with an average delta E > of 1.08 and a peak that is 5.76. I am wondering if there might be some > problem somewhere in the lcms code when running on an amd64 machine? I > un-installed and reinstalled each version several times to make sure that the > only difference was the version of lcms. > > Anyone have any ideas about what might be going on? Looks like the ABI was changed incompatibly (though the library version is still liblcms.so.1) :-( The difference is obviously in the GAMMATABLE structure, which got some new fields, and every program which either references fields in a GAMMATABLE structure, or which uses sizeof(GAMMATABLE) or which declares variables of type GAMMATABLE (and not just pointers) may now get problems if it is not recompiled with the new lcms.h 1.15. Have you tried to recompile everything with the 1.15 lcms header files? Or did you just run the binary compiled with 1.14 header files with the 1.15 libraries? Regards, Gerhard |
From: Hal V. E. <hv...@as...> - 2006-02-23 01:30:29
|
On Wednesday 22 February 2006 05:01 pm, Gerhard Fuernkranz wrote: > Hal V. Engel wrote: > > I just did some testing with lcms 1.15 and I was not able to reproduce > > this particular problem. But LPROF, at least on my machine, had other > > much more significant problems with 1.15 as the profiles generated were > > very bad. The profiles had very high delta E numbers (52 average and a > > peak of 124.5). With 1.14 installed the same setup produced a profile > > with an average delta E of 1.08 and a peak that is 5.76. I am wondering > > if there might be some problem somewhere in the lcms code when running on > > an amd64 machine? I un-installed and reinstalled each version several > > times to make sure that the only difference was the version of lcms. > > > > Anyone have any ideas about what might be going on? > > Looks like the ABI was changed incompatibly (though the library version > is still liblcms.so.1) :-( > > The difference is obviously in the GAMMATABLE structure, which got some > new fields, and every program which either references fields in a > GAMMATABLE structure, or which uses sizeof(GAMMATABLE) or which declares > variables of type GAMMATABLE (and not just pointers) may now get > problems if it is not recompiled with the new lcms.h 1.15. > > Have you tried to recompile everything with the 1.15 lcms header files? > Or did you just run the binary compiled with 1.14 header files with the > 1.15 libraries? > > Regards, > Gerhard Gerhard, I just build the new version of lcms and ran LPROF against it without rebuilding it. I don't know what I was thinking as the first thing I should have done once the new version of lcms was installed is to rebuild LPROF just in case something changed like it had in fact done this time. I just rebuilt LPROF against the new version of lcms and it runs fine. Including not being able to reproduce the problem that Cory reported with the profile checker. So Cory's problem is not 1.15 specific. I will have to revert back to lcms 1.14 for a while since I will have to rebuild a number of other apps if I don't. But it is good to know that lcms 1.15 does not appear to have any problems. Hal |