Thread: [Lcms-user] cmsChangeBuffersFormat?
An ICC-based CMM for color management
Brought to you by:
mm2
From: Steve M. <sm...@mu...> - 2010-06-25 20:01:22
|
Is there an equivalent to cmsChangeBuffersFormat in lcms2? We had been calling it prior to cmsDoTransform. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multiad.com |
From: Steve M. <sm...@mu...> - 2010-06-30 18:18:23
|
Hello? No responses yet about this question. On Jun 25, 2010, at 15:01:15, Steve Mills wrote: > Is there an equivalent to cmsChangeBuffersFormat in lcms2? We had been calling it prior to cmsDoTransform. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multiad.com |
From: <mar...@li...> - 2010-06-30 18:55:55
|
Quoting Steve Mills <sm...@mu...>: > Hello? No responses yet about this question. > >> Is there an equivalent to cmsChangeBuffersFormat in lcms2? We had >> been calling it prior to cmsDoTransform. I did an entry in the development blog a few days ago http://littlecms2.blogspot.com/2010/06/i-got-this-question-twice-so-here-are.html Regards Marti |
From: Steve M. <sm...@mu...> - 2010-06-30 19:22:24
|
On Jun 30, 2010, at 13:17:45, mar...@li... wrote: > http://littlecms2.blogspot.com/2010/06/i-got-this-question-twice-so-here-are.html The problem is, regardless of how this affects performance, we now have to rip out and rewrite a large part of our code. It also means that everything will work differently when the user is using lcms than when they are using ColorSync. Previously, we could allocate a number of transforms (or color worlds when using ColorSync) for drawing to screen; one for drawing cmyk solid colors, one for drawing a certain bitmap with a certain input profile, etc. Those transforms (or worlds) could be kept around for long periods of time until the user changed something, and it didn't matter what the format of the input or output was, it just worked (it just worked in ColorSync, and the cmsChangeBuffersFormat made it work in lcms). Now we'll have to keep more transforms around based on the input/output formats, and we'll have to crowbar the code to create them in a totally different place, one that knows about the input/output format. You can see why I'm not pleased about this change. You can't just stick the cmsChangeBuffersFormat back in for those of us who prefer leaving our code the way it was while going through the lcms to lcms2 upgrade? _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multiad.com |
From: <mar...@li...> - 2010-07-01 08:31:46
|
Hi, > The problem is, regardless of how this affects performance, we now > have to rip out and rewrite a large part of our code. It also means > that everything will work differently when the user is using lcms > than when they are using ColorSync. Previously, we could allocate a > number of transforms (or color worlds when using ColorSync) for > drawing to screen; one for drawing cmyk solid colors, one for drawing > a certain bitmap with a certain input profile, etc. Those transforms > (or worlds) could be kept around for long periods of time until the > user changed something, and it didn't matter what the format of the > input or output was, it just worked (it just worked in ColorSync, and > the cmsChangeBuffersFormat made it work in lcms). I see. Maybe I could add this function to work on non-optimized tranforms. Please note that means an important throughput penalty, but maybe that is not so important. Ok, let me some days to figure out the required changes. Thanks for spotting the issue. Regards Marti. |
From: Steve M. <sm...@mu...> - 2010-07-01 12:41:07
|
On Jul 1, 2010, at 02:53:33, mar...@li... wrote: > I see. Maybe I could add this function to work on non-optimized tranforms. > Please note that means an important throughput penalty, but maybe that > is not so important. Ok, let me some days to figure out the required changes. Thanks for looking into it. It really is nice when a major update to a code library requires no changes in the user's code. This might not always be possible, but it's a good way to think when planning an update. _________________________________________________________ Steve Mills Me: 952-401-6255 Senior Software Architect MultiAd sm...@mu... www.multiad.com |