[Gimp-developer] GSoC Status Report for pygimp
-BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, a short update what I did during the last few weeks. * I started with moving the package structure to a more hierarchical one. With a gimp package on top and several subpackages like gimp.colors, gimp.enums, gimp.ui. * I also changed gimp.enums to use GEnum objects instead integers for the enums. * Gradient, Brush, Palette and Pattern objects have been mapped in pure python. Although I'm not that happy with gimp.Gradient and gimp.Palette: The problem is that in python you can not copy a object implicitly by value. Assigning a object to a name copies the reference and increases the refcount. Image the following code: palette.entries[0] = palette.entries[1] palette.entries[0].color = gimp.colors.RGB(0, 0, 0) From a python point of view it should change the color of entry 0 and 1. But in gimp palette entries can only accessed by their index. So I ended up writing some code that tracks which GradientEntry is assigned to what indices. The problem starts when a script uses gimp.pdb.gimp_palette_delete_entry in parallel. A Gradient object can not be notified when a entry is deleted so the indices get all wrong. Something similar is true for the gradient wrapper. * I added a gimp.context module that wraps all the gimp_context_* functions. * Added wrapper code for most of the missing gimp widgets. So gimp.ui is almost complete now except for a problem with Preview objects. Also some methods need a more pythonic interface. * Added a unittest that test if the wrapped widget methods at least do not crash and accept the right parameters. * Additionally I found and fixed some bugs in pygimp. What comes next: * Do something about the problems with gimp.Gradient and gimp.Palette described above. * I have been looking into wrapping libgimpmath. But I'm not sure how to handle it. The matrix and vectors code looks incomplete and inconsistent. Some objects are GObjects others are not. * The pygobject system complains when a object is not constructable with properties. So I'll look into porting the widgets that don't support it, but I will need some advice how to it the right way. * In my opinion the error messages in pygimp-pdb are a bit unspecific. So I'll try to rewrite parts in pygimp-pdb.c to give better error messages. Lars -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVWh6BX4mSR26RiMRAl+oAJ49fEOfqkANQTuuKS8mDzoueGLWFQCfY+KY Avt349hZp0rImYXhrTzXUcc= =/DOD -END PGP SIGNATURE- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Image color representation?
Hi! I am wondering which data type GIMP uses to represent the color in a pixel of an image? 8 bits/channel? 12 or 16 bits? float? According to http://pippin.gimp.org/image_processing/chap_dir.html#id2525344, there seems to be some different representation types, but glaus is somewhat unknown to me, though. I’m having a bit of trouble myself deciding which type I should have in the program I’m going to make, to use for each channel. If I use 8 bits per channel, the different functions will probably run a bit faster than if I use floating point values. If you should, by chance, use floating point representation of the colors, is there some function in GIMP to read a jpg image directly into an image with floats, instead of using some function already existing to read it into an image with 24-bit color and then convert it to floating point values? /Kristofer -- View this message in context: http://www.nabble.com/Image-color-representation--tp17855048p17855048.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC Status Report for pygimp
On Sunday 15 June 2008, Lars-Peter Clausen wrote: Thank you for the e-mail -- there is a lot fo thing going on. I am not shure if I understood the exact nature of the palletes and gradients problems you describe - but you have to take care to let they behave like python - even if it is not the most intuitive thing when one does not understand what python is doing. if palette.entries[0] = palette.entries[1] palette.entries[0].color = gimp.colors.RGB(0, 0, 0) From a python point of view it should change the color of entry 0 and 1. This is what should happen in pygimp. We should introduce a copy methotd to gimp colors, if they don't have. So one would do: palette.entries[0] = palette.entries[1].copy() to duplicate the entry. (this won't be a problem, and will be even less of an issue if it is properly documented on the palette and gradient classes doc strings ) * I have been looking into wrapping libgimpmath. But I'm not sure how to handle it. The matrix and vectors code looks incomplete and inconsistent. Some objects are GObjects others are not. hmmm..Python cando it is own math -- but it may be possible that are function calls that use the matrix structs and others as they are defined in libgimpmath - maybe you could use ctypes there? It is an easy wrapping around C dynamic libraries taht is made in python only at runtime (Ctypes is part of standard python distro as of python 2.5 so it won't increase our dependencies). On the other hand, if the structs desscribed in the libgimpmap/*h files are not usefull for other function calls made from python, just docuemtning what is available and suggesting how to do it in NumPy would be enough, IMO. Thank you for the post. I think it is a nice oportunity for everyone to see the money they make google win with their eyeballs is being well spent! :-) js -- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
Gimp currently uses 8bits/channel. Some 16/12bit formats (eg TIFF) are supported only by scaling the data down into 8 bits. The colors used in color selectors, and 'single' colors are represented as floating point values. I suggest investigating GEGL (gegl.org), which can provide pixel data in a wide range of formats, and load images, if you require 8bpp support. GIMP 2.5+ already depends on GEGL. (also, with a 256-entry lookup table, converting 8bpp-float is trivially easy and fast to implement) On Mon, Jun 16, 2008 at 8:25 AM, TriKri [EMAIL PROTECTED] wrote: Hi! I am wondering which data type GIMP uses to represent the color in a pixel of an image? 8 bits/channel? 12 or 16 bits? float? According to http://pippin.gimp.org/image_processing/chap_dir.html#id2525344, there seems to be some different representation types, but glaus is somewhat unknown to me, though. I'm having a bit of trouble myself deciding which type I should have in the program I'm going to make, to use for each channel. If I use 8 bits per channel, the different functions will probably run a bit faster than if I use floating point values. Premature optimization is the root of all evil. I know it's tempting, but it's really good practice to only optimize when a) there is something fundamentally wrong with the approach taken by the algorithm, or b) you have proof that that specific code is unacceptably slow (bottlenecking the process) If you should, by chance, use floating point representation of the colors, is there some function in GIMP to read a jpg image directly into an image with floats, instead of using some function already existing to read it into an image with 24-bit color and then convert it to floating point values? /Kristofer -- View this message in context: http://www.nabble.com/Image-color-representation--tp17855048p17855048.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Image color representation?
On Sunday 15 June 2008, TriKri wrote: Hi! I am wondering which data type GIMP uses to represent the color in a pixel of an image? 8 bits/channel? 12 or 16 bits? float? Hi! The gimop currently works with 8 bit per channel only. According to http://pippin.gimp.org/image_processing/chap_dir.html#id2525344, there seems to be some different representation types, but glaus is somewhat unknown to me, though. I’m having a bit of trouble myself deciding which type I should have in the program I’m going to make, to use for each channel. If I use 8 bits per channel, the different functions will probably run a bit faster than if I use floating point values. In a new program dealin gwith images, you certainly should take a close look in GEGL - the Generic Graphics Library - which has been though from the beggining as a library to enable GIMP to work in other color dephs in a clean way. Most likely, if your program needs to perform operations in an image you will be fine implementing these operations in GEGL thenselves, and then havign the remaning of the program as a UI around the GEGL calls (or even as a GIMP Plug-in if the users of your programs are likely to do other things with the images before or after your program do its thing on them) If you should, by chance, use floating point representation of the colors, is there some function in GIMP to read a jpg image directly into an image with floats, instead of using some function already existing to read it into an image with 24-bit color and then convert it to floating point values? yes, GEGL can do that for you (but not GIMP). /Kristofer js -- (ps. http://www.gegl.org/ ) ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSoC Status Report for pygimp
Hi Lars-Peter, On Mon, Jun 16, 2008 at 4:37 AM, Lars-Peter Clausen [EMAIL PROTECTED] wrote: -BEGIN PGP SIGNED MESSAGE- Hash: SHA1 Hi, a short update what I did during the last few weeks. * I started with moving the package structure to a more hierarchical one. With a gimp package on top and several subpackages like gimp.colors, gimp.enums, gimp.ui. * I also changed gimp.enums to use GEnum objects instead integers for the enums. * Gradient, Brush, Palette and Pattern objects have been mapped in pure python. Although I'm not that happy with gimp.Gradient and gimp.Palette: The problem is that in python you can not copy a object implicitly by value. Assigning a object to a name copies the reference and increases the refcount. Image the following code: palette.entries[0] = palette.entries[1] palette.entries[0].color = gimp.colors.RGB(0, 0, 0) From a python point of view it should change the color of entry 0 and 1. I disagree. From the code you showed above, changing palette.entries[1] should effect palette.entries[0], but not vice versa. Anyway, I really recommend following NumPy's lead here; it's a tried and tested solution in it's field (array manipulation), and it's a pleasure to use -- I use it myself for manipulating colors, palettes, and images. NumPy approach looks like: palette.entries[0] = palette.entries[1] # copy palette entry in gimp palette entries can only accessed by their index. So I ended up writing some code that tracks which GradientEntry is assigned to what indices. The problem starts when a script uses gimp.pdb.gimp_palette_delete_entry in parallel. A Gradient object can not be notified when a entry is deleted so the indices get all wrong. Something similar is true for the gradient wrapper. * I added a gimp.context module that wraps all the gimp_context_* functions. This, and the gradient+palette wrappers, are very good news (I'll still end up wrapping your modules, because I need custom behaviour for fg and bg attributes, as well as additional functionality for palettes and gradients. I expect for most other people, your new classes will be sufficient by themselves). I look forward to seeing the final result of your good work on this. Oh! Are they (Gradient, Palette, Pattent) subclassable? If not, no big deal; it just would be nice to be able to add methods. I'm also curious about the Pattern interface. Does it allow you to directly replace the pixels of a pattern with new pixels, or not? * Added wrapper code for most of the missing gimp widgets. So gimp.ui is almost complete now except for a problem with Preview objects. Also some methods need a more pythonic interface. * Added a unittest that test if the wrapped widget methods at least do not crash and accept the right parameters. * Additionally I found and fixed some bugs in pygimp. What comes next: * Do something about the problems with gimp.Gradient and gimp.Palette described above. As I said before, I recommend NumPy's approach highly. Assigning by reference in such a way is too potent an opportunity for confusion. Say that I do palette.entries[0] = palette.entries[1] palette.entries[1] = palette.entries[2] palette.entries[2] = palette.entries[3] Then assigning to palette.entries[3] should change 0,1,2, and 3. That seems very confusing and prone to non-obvious side-effects. (oh, BTW, palette[index].color sounds better than palette.entries[index].color to me. Is there any reason that this could not work?) * I have been looking into wrapping libgimpmath. But I'm not sure how to handle it. The matrix and vectors code looks incomplete and inconsistent. Some objects are GObjects others are not. * The pygobject system complains when a object is not constructable with properties. So I'll look into porting the widgets that don't support it, but I will need some advice how to it the right way. * In my opinion the error messages in pygimp-pdb are a bit unspecific. So I'll try to rewrite parts in pygimp-pdb.c to give better error messages. Lars -BEGIN PGP SIGNATURE- Version: GnuPG v1.4.6 (GNU/Linux) Comment: Using GnuPG with Mozilla - http://enigmail.mozdev.org iD8DBQFIVWh6BX4mSR26RiMRAl+oAJ49fEOfqkANQTuuKS8mDzoueGLWFQCfY+KY Avt349hZp0rImYXhrTzXUcc= =/DOD -END PGP SIGNATURE- ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer -- David ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
