Hi, cmsChangeBuffersFormat is gone in 2.0, and there is a good reason to do that: optimization. When you create a transform, you supply the profiles and the expected buffer format. Then, the engine, on depending on things like number of channels and bit depth can choose to implement such transform in different ways. Let's take an example. If you create a AdobeRGB to sRGB transform using TYPE_RGB_8 for both input and output, the engine can guess that the maximum precision you would require is 8 bits, and then simplify the curve and matrix handling to, for example 1.14 fixed point. This precision is enough for 8 bits but not for 16 bits, so if you change the format after creating the transform to TYPE_RGB_16, you would end either with artifacts or throughput loss.
Remember lcms 2 allows you to close the profiles after creating the transform. This is very convenient feature but prevents to recalculate the transform by reading the profile again. And there are situations, MPE for example when different precision means different tags. Overall I think the balancing of losing "change format" versus optimization and early profile closing is good. Otherwise you can always create a new transform for each format. Since you can close the profiles after creation, the amount of allocated resources should remain low. Regarding the one-pixel formatters, I evaluated the possibility of doing that, but changes were significant and would break such quantity of (my company) code that the option was discarded for 2.0, but it certainly can be implemented by a plug-in as a custom intent and maybe it would be part of the engine in a future. So, many thanks for your suggestion. Regards Marti Quoting Prevost Jerome <j.prev...@lectra.com>: > Hello, > > I just take a look at migrating to V2, but don't find the > cmsChangeBuffersFormat function any more (or an equivalent). As I use > it all the time (because I can't know in advance what is the buffer > format will be), how can I change it without recreating the transform > (which would be way too slow) ? > > About this subject, in fact, the way the buffers are defined seems > very complicated and restrictive (I can not for example use buffers > with transparency for each channel) because of the exhaustive aspect. > I used to use the Kodak CMS a few years ago and they chose a very > simple and universal way to describe buffers (what they called > layouts) and they don't use function pointers (that can not be > inlined) internally for each buffer format. The internal > implementation (I got the source code) is much simpler and compact > without the whole set of input/output functions because of the buffer > description. I don't know if you know the old Kodak CMM, I can give > you the buffer structure (a C struct, actually) and you will see how > simple it is for the user and for the internal implementation of the > CMM ! > > I was reluctant to migrate to V2 because I made a lots of changes > into the v1.19, changing all these functions to accept a buffer > instead of a single pixel. So the buffer goes directly to the lowest > level of the transform. By doing this, I could get a speedup from > ten to twenty for any type of transform, most of the time is lost > across calls. In addition to that, using OpenMP adds somme more speed > and I could get, with these (very boring !) modifications, something > better than the Kodak CMS. > > The V2 is a large improvement into the architecture, a very elegant > one ! The buffer part is the weakest part of the edifice now. But > even with that (and all the modification I will do again), I think > it's worth migrating. > Perhaps in V3 ! > > Thanks in advance, > > J. > ------------------------------------------------------------------------------ _______________________________________________ Lcms-user mailing list Lcms-user@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/lcms-user
