From: Frédéric <fre...@gb...> - 2008-02-21 12:51:40
|
Hello, I finally released a first beta version of ImageCms, a littlecms-based module for PIL based on the old pyCMS code: http://trac.gbiloba.org/ImageCms ImageCms is more object oriented, and a few minors bugs have been corrected. I also removed useless functions, but I plan to add more features. This is a first draft ;o) Feel free to send me comments/requests/bug reports. I think the image-sig list is the right place for that. Regards, -- Frédéric |
From: Guy K. K. <G....@ma...> - 2008-02-24 03:33:25
Attachments:
ClassDiagram.png
|
Kia ora Frédéric, some feedback on the module ... I've also created a class diagram (really simple) with eric3 to outline the structure. I'm a visual person ... Of course it does not contain the module functions versions() and profileToProfile() ... On Fri, 22 Feb 2008 1:51:33 am Frédéric wrote: > I finally released a first beta version of ImageCms, a littlecms-based > module for PIL based on the old pyCMS code: > > http://trac.gbiloba.org/ImageCms > > ImageCms is more object oriented, and a few minors bugs have been > corrected. I also removed useless functions, but I plan to add more > features. This is a first draft ;o) * version() crashes: "Segmentation fault (core dumped)" Also no unit test is available for this function. * private class members: You've consequently used the double-underscore notation to indicate private members in your class. This is the way that prohibits access to these members. Current accepted good practice is to use the single underscore to just *indicate* the privateness of a member, rather than to prohibit its access from outside. The double-underscore notation should be usually used only to prevent potential clashes for specific insurance reasons [1]. * What is this line supposed to do? colorTemp = int(colorTemp + 0.5) In the case colorTemp is declared to be an int, and it is tested against the int type. So this line seems redundant. Also there is no test for "positiveness" of the int, which is implied (and sensible for a Kelvin temperature) by the exception raised. * Profile.profile and Transform.transform seem to be interfaces to the native C library. It would make sense to declare these private as _profile and _transform. * some suggestions for further functionality: * Profile.supportedIntents() method: returns a list of supported rendering intents. Maybe even a dict with the (integer) intent as a key and a corresponding string description as a value. * Transform.profileConnectionSpace: returns the used PCS (e. g. XYZ, LAB) * Transfor.setPCS() method: Don't know whether that would be good/possible. * Transform.doToPCS() method: transforms from source space to PCS only. * Transform.doFromPCS() method: transforms from PCS to target space. OK, that's just from a bit of playing around with the code so far. > Feel free to send me comments/requests/bug reports. I think the image-sig > list is the right place for that. As I'm not subscribed to image-sig, but received this info here on lcms-user, I believe it's still OK. If not, just let me know. After all, it's in a way a Pythonic OO wrapper to lcms. Guy [1] http://www.thescripts.com/forum/thread21542.html -- Guy K. Kloss Institute of Information and Mathematical Sciences Te Kura Putaiao o Mohiohio me Pangarau Room 2.63, Quad Block A Building Massey University, Auckland, Albany Private Bag 102 904, North Shore Mail Centre voice: +64 9 414-0800 ext. 9585 fax: +64 9 441-8181 eMail: G....@ma... http://www.massey.ac.nz/~gkloss/ |
From: Frédéric M. <fre...@gb...> - 2008-02-24 21:48:12
|
On dimanche 24 février 2008, Guy K. Kloss wrote: > some feedback on the module ... I've also created a class diagram > (really simple) with eric3 to outline the structure. I'm a visual person > ... Thank you very much for the class-diagram... and the bug report. I will take all this into account. > [...] > > Feel free to send me comments/requests/bug reports. I think the > > image-sig list is the right place for that. > > As I'm not subscribed to image-sig, but received this info here on > lcms-user, I believe it's still OK. If not, just let me know. After all, > it's in a way a Pythonic OO wrapper to lcms. Well, ImageCms uses both PIL and little cms libs, so I don't know which mailing-list is better to use. Certainly both, depending of the problem, but it is may be not a good idea, as it will spread out discussions, and lead to redundant questions/answers. On another hand, pure python problems should better be discussed on image-sig ml, as they will bother people here... Sme for little cms related problems on image-sig ml... What little cms ml users think? Should I tell people to use both lists, depending on the problem? Only little cms? Only image-sig? -- Frédéric http://www.gbiloba.org |