Hi James, Yes, this is a known glitch of current implementation. Now, the openProfileFromMem() does store the profile in a temporary file and then proceed as a normal file. Obviously, this is less than optimal and disallow the use of lcms in some environments, like firmware, for example. In past has been useful for debug purposes, but right now the benefits it give are at least dubious.
FYI, I'm right now working in the incoming lcms 1.10 that will incorporate this, among some other features, like named color profiles. I hope to have something working soon, but the task of debugging & writing documentation will take a bit more. Can't promise dates, but I hope to have all ready for Christmas. Oh, of course your patch will be welcome :-) Best Regards, Mart� Maria The little cms project http://www.littlecms.com [EMAIL PROTECTED] ----- Original Message ----- From: "James Burgess" <[EMAIL PROTECTED]> To: "Mart� Maria" <[EMAIL PROTECTED]> Cc: <[EMAIL PROTECTED]> Sent: Wednesday, October 23, 2002 8:14 PM Subject: Re: [Lcms-user] Re: tifficcc and jpegicc > Marti, > I'd like to propose a bit of a change in lcmsio1.c. The purpose of > this is to help people integrating lcms into other existing > applications and libraries. The problem comes from the implementation > of how LoadProfileFromMemory works and how in fact file reading in > general happens. I'll outline the problem, then my proposal here. > > The current implementation (you know all this but for other readers > this is necessary) right now all profile reading happens by lcms making > calls the fopen() and friends, which is true even of opening profiles > from memory. Behind the scenes those are written to a file. I want to > use lcms in an environment where I already have the profiles in memory > (in opaque chunks of bytes) and I want to hand them to lcms. I don't > for a variety of reason want to open any more files and more > importantly I'm going to have a lot of profiles open (for reading). > > I don't really want to change from using fopen() for files as we > pretty much have that on most platforms now. But for reading from > memory I really don't think writing a temp file is necessary or > desirable. My solution is to copy what many other libraries do which is > to centralize all of the IO into a set of function pointers in the > profile structure which can them be implemented in any way the > application wants. So a few new fields would be added to the profile > structure with the following types. > > typedef int (LCMSOpenFileProc*)(const char* path, const char*mode, void > *clientData); > typedef int (LCMS OpenFromMemFileProc*)(void* bytes, size_t length, > const char*mode, void *clientData); > typedef size_t (LCMS ReadProc*)(void *clientData, void* data, size_t > size, size_t count); > typedef size_t (LCMS WriteProc*)(void *clientData, const void* data, > size_t size, size_t count); > typedef int (LCMS SeekProc*)(void *clientData, ssize_t size, int > whence); > typedef int (LCMS CloseProc*)(void *clientData); > > Two flavors of each of the profile creating functions are then provided > - one with the default implementation and one where you get to pass in > a value for each of the above fields. The open-from-memory call can > then have a default implementation that just uses pointer arithmetic to > move around some memory. > > A couple of issues come up which are the semantics of having the > profile "open" and whether the lcms library is allowed to do a write at > any moment. I think this should just be cleared up with extending the > open mode parameter to allow a "r" as well as a "w". > > What do you think? Yes I'm going to volunteer a patch. > > > > ------------------------------------------------------- This sf.net email is sponsored by: Influence the future of Java(TM) technology. Join the Java Community Process(SM) (JCP(SM)) program now. http://ad.doubleclick.net/clk;4729346;7592162;s?http://www.sun.com/javavote _______________________________________________ Lcms-user mailing list [EMAIL PROTECTED] https://lists.sourceforge.net/lists/listinfo/lcms-user
