Re: [Gimp-developer] Slow preview on highres images]
Hi, Damien Genet [EMAIL PROTECTED] writes: Why can't you launch a « Gimp Fund » through paypal, like the Blender foundation did ? I think that the Gimp has much more visibility than Blender did, and would have no problems raising money. Actually, it may even help to boost the development. I'm not sure if it would boost development, it might as well hurt it. The problem with money is that we would somehow have to decide how to spend it. Paying developers from such a fund could cause quite some disagreements. If others are paid for their contribution, why would anyone want to contribute unless (s)he's paid as well? I do believe however that a GIMP Foundation of some sort would make sense. It would make it a lot easier to raise fundings for events like developer conferences and would thus allow us to do them more frequently. I hope that we can discuss (or maybe even found) such an organization on the GIMP Developers Conference this summer. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images]
Hi, Le mer 11/06/2003 à 11:45, Sven Neumann a écrit : I'm not sure if it would boost development, it might as well hurt it. The problem with money is that we would somehow have to decide how to spend it. Paying developers from such a fund could cause quite some disagreements. If others are paid for their contribution, why would anyone want to contribute unless (s)he's paid as well? Yes, you are certainly right, but this money could also be used to organize events, and pay travel expenses or buy some hardware if a main developper needs it, like the AbiWord ppl does. That's really less controversial, but could prove to be really usefull. -- Dam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images]
Sven Neumann wrote: Hi, Damien Genet [EMAIL PROTECTED] writes: Why can't you launch a « Gimp Fund » through paypal, like the Blender foundation did ? I think that the Gimp has much more visibility than Blender did, and would have no problems raising money. Actually, it may even help to boost the development. I'm not sure if it would boost development, it might as well hurt it. The problem with money is that we would somehow have to decide how to spend it. Paying developers from such a fund could cause quite some disagreements. If others are paid for their contribution, why would anyone want to contribute unless (s)he's paid as well? I do believe however that a GIMP Foundation of some sort would make sense. It would make it a lot easier to raise fundings for events like developer conferences and would thus allow us to do them more frequently. I hope that we can discuss (or maybe even found) such an organization on the GIMP Developers Conference this summer. Sven I am on it. I'll have a presentation to give on the subject. -- Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images]
On Wed, Jun 04, 2003 at 05:25:14PM +0200, Feczak Szabolcs wrote: AFAIK, there are no plans to do such an improvement. Considered that we still lack some funding for our developers conference this summer, perhaps we could be persuaded to give it a try. Ok, what do you need to be more persuaded ? pls reply -- _(_)_ (_. o_)F3CZ0 (_,) http://feczo.koli.kando.hu ()__ // // ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images]
Hi, Feczak Szabolcs [EMAIL PROTECTED] writes: AFAIK, there are no plans to do such an improvement. Considered that we still lack some funding for our developers conference this summer, perhaps we could be persuaded to give it a try. Ok, what do you need to be more persuaded ? First of all, sorry for not getting back to you earlier. You raised a very difficult question. To understand the difficulties, you need to know that we are very close to a major release and that we are more or less feature-frozen. More or less means that there are a few outstanding features that have long been planned to go in and that people are already working on. These features are supposed to go into the next release. Everything else is postponed for after the release. What you are asking for is a major change. It requires to introduce a new framework to the core that provides scaled-down previews of all drawables. A lot of operations like for example transformations would benefit from such a framework so we definitely want to introduce it at some point. However I feel that it is too much of a change right now. It would delay the release and we are already behind our time schedule. So basically, what we need to be more persuaded is time. To some extent, time can be bought. You could for example offer money to GIMP developers in order to allow them to work full-time on this feature. That would not necessarily persuade me and Mitch as the maintainers to let the feature go in before the next release. But if someone would come up with a well-designed and working patch, how could we not accept it? We haven't yet decided how we want to proceed after the release. This is something we will discuss at the GIMP Developers Conference this summer. As I've said, we are still looking for sponsors for this conference. Most developers are not able to pay for their travel costs, so we are dependant on funding. Of course we would appreciate if you'd decide to help us with the conference but I can not promise you any features let alone a time schedule for features. Your funding would certainly help GIMP development and we would be happy to mention your company's name as a conference sponsor. Your money would certainly help to improve GIMP but I cannot sell any features to you. Especially not at this point of development. I'd be happy if you nevertheless decided to help us with the conference. We already got some fundings from the FSF but we are still lacking about 5000 EUR. That's not much for a larger company and any donations would help. So if you, or anyone else reading this, is willing and able to help, please let us know. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images]
On Tue, Jun 10, 2003 at 05:02:22PM +0200, Sven Neumann wrote: First of all, sorry for not getting back to you earlier. ok, thanks better later than never :) I can better understand your situation by now. Im just wondering how could this avoid your attention during the core code development, since this is a fundamental flaw I think. In my imagination it looks like during testing you have choosen images only with small amount of pixels or something like that, or maybe in the beginning the aim was to satisfy only a lower quality deamand for web graphics, not the professional digital imaging (which obiviously was not so popular in the early stage of gimp development). Im just guessing it is not against anyone, Im just curious .. you might tell me the real history if gimp from that aspect. That's not much for a larger company and any donations would help. So if you, or anyone else reading this, is willing and able to help, please let us know. Well, saidly we are not out of the larger companies. Our organization is really small, it is a photo shop indeed. So I guess we stuck to Photoshop and windows till the case solved. We will kindly support you from our profit if we can benefit from your software, but at this point this is not much, maybe a 100Eu or sg. like that. -- _(_)_ (_. o_)F3CZ0 (_,) http://feczo.koli.kando.hu ()__ // // ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images]
Hi, Le mar 10/06/2003 à 17:02, Sven Neumann a écrit : I'd be happy if you nevertheless decided to help us with the conference. We already got some fundings from the FSF but we are still lacking about 5000 EUR. That's not much for a larger company and any donations would help. So if you, or anyone else reading this, is willing and able to help, please let us know. Why can't you launch a « Gimp Fund » through paypal, like the Blender foundation did ? I think that the Gimp has much more visibility than Blender did, and would have no problems raising money. Actually, it may even help to boost the development. Thanks, -- Dam ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images]
Feczak Szabolcs [EMAIL PROTECTED] writes: Changing the color balance/brightens-contrast/ color curves are significantly slower in gimp vs. photoshop on the same machine. The problem is not the processing time alone, but the preview takes the same amount of time as the final processing. I have relized, that gimp calculates all the data in preview mode as I would have pressed the ok button. Very well spotted. Other good idea came from my friend: creating a smaller image in memory, which has the resolution of the screen and calculating the preview on that image. That is obviously the approach that should be taken. AFAIK, there are no plans to do such an improvement. Considered that we still lack some funding for our developers conference this summer, perhaps we could be persuaded to give it a try. Ok, what do you need to be more persuaded ? -- _(_)_ (_. o_)F3CZ0 (_,) http://feczo.koli.kando.hu ()__ // // ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images
I was thinking abiut the subject , and came to a way of doing it - if PDB calls can be made normaly from inside these plugins - which I assume thay can, without problens. Therefore, if you will allow me, I will describe what I was thinking in gimp pseudocode. Someone more familiar to the core than I could tell me if there is a fundamentla flaw. If it allright, than I think it could be implemented in less than a couple of weeks: In summary before for performing a preview in such filters, this could be done: 1 - Test from viewing window and scale, and from memory avaliability, if it's worth to use these optimizations. 2 - Create a new image - new drawable if we are working in a single layer image, or top visible layer in normal mode. 3 - If the current selection is larger than the viewable area store it somewere, and intersect it with the viewable area 4 - if the image is zoomed out copy all visible layers to the new image created, and scale it down in linear mode, in a manner that each pixel in it is equivalent to a pixel on the screen at the subject image. 5 - perform the filter action ont he corresponding layer on the new image. 6 - copy visible the new image 7 - create a new temporary drawable on top of all visible layers on the subject image 8 - paste draft image visible contentes on new drawable, position and scale it accordingly. 9 - repeat 5,6 and 8 until the filter is commited or cancelled 10 - restore selection, delete temporary layer and temporary images 11 - commit changes. What do you think about it? Of what I've seen on the code, it seens that each such filter does it's own changes on the images. They all would have to be individually modified to use the steps above. Still doesn't seen hard: a - if filter is in preview mode, calls a procedure that makes steps 1 - 4 above, and return a new drawable. b - perform filter action on drawablem and call a procedure that will perform 5, 6,7 (once) and 8 above. c - on ok or cancel, call something to make 10, and perform 11 Feczak Szabolcs wrote: Feczak Szabolcs [EMAIL PROTECTED] writes: Changing the color balance/brightens-contrast/ color curves are significantly slower in gimp vs. photoshop on the same machine. The problem is not the processing time alone, but the preview takes the same amount of time as the final processing. I have relized, that gimp calculates all the data in preview mode as I would have pressed the ok button. Very well spotted. Other good idea came from my friend: creating a smaller image in memory, which has the resolution of the screen and calculating the preview on that image. That is obviously the approach that should be taken. AFAIK, there are no plans to do such an improvement. Considered that we still lack some funding for our developers conference this summer, perhaps we could be persuaded to give it a try. Ok, what do you need to be more persuaded ? JS -- ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images
Hi, Joao S. O. Bueno [EMAIL PROTECTED] writes: I was thinking abiut the subject , and came to a way of doing it - if PDB calls can be made normaly from inside these plugins - which I assume thay can, without problens. We are not talking about plug-ins here. Previews for plug-ins are handled by the GimpPreview widget that Ernst was working on and should find its way into CVS soon (at least I hope that it will). We are talking about tools here. The strategy how to handle this stuff is pretty obvious and resembles what you suggested. The fact is that such a change would affect a lot of core code since it should be implemented on a relatively low level. This is something we can not do at this point of the development. It should however be a design goal for the upcoming redesign of the GIMP core. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images
Hi, Feczak Szabolcs [EMAIL PROTECTED] writes: Changing the color balance/brightens-contrast/ color curves are significantly slower in gimp vs. photoshop on the same machine. The problem is not the processing time alone, but the preview takes the same amount of time as the final processing. I have relized, that gimp calculates all the data in preview mode as I would have pressed the ok button. Very well spotted. I have Also noticed, that during the process it divides the picture into smaller squares top-down, and the change takes effect continously in these squares (in preview mode also). Photoshop also uses these squares, but it uses only about 6/picture while gimp is using much-moch more smaller (I couldn't count). I think this is the source of the difference in the preview processing time. I don't think the number of tiles makes any difference. The problem is indeed that the preview is implemented by doing the color transformation on the full-size image data. I think if it is not solved, maybe preview should be done through sdl or xvid or whatever instantly (but maybe the videocard controll gives slightly different result than the later calculated image after OK button...) Sorry, SDL or similar approaches are not an option here. Not only would they be highly unportable, there's also no way to ensure that the result matches the actual color transformation you want to preview. Other good idea came from my friend: creating a smaller image in memory, which has the resolution of the screen and calculating the preview on that image. That is obviously the approach that should be taken. So long Im not into C programming so much, so I can't work it out within a reasonable time, but please let me know if you are willing to do some improvements like this, since at the moment this slowness on previews holds us back from changeing. If we can change of course we can make some donations to the community. AFAIK, there are no plans to do such an improvement. Considered that we still lack some funding for our developers conference this summer, perhaps we could be persuaded to give it a try. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Slow preview on highres images
On Mon, 02 Jun 2003 18:28:42 +0200, Sven Neumann [EMAIL PROTECTED] wrote: Feczak Szabolcs [EMAIL PROTECTED] writes: Changing the color balance/brightens-contrast/ color curves are significantly slower in gimp vs. photoshop on the same machine. The problem is not the processing time alone, but the preview takes the same amount of time as the final processing. I have relized, that gimp calculates all the data in preview mode as I would have pressed the ok button. Very well spotted. [...] The problem is indeed that the preview is implemented by doing the color transformation on the full-size image data. [...] Other good idea came from my friend: creating a smaller image in memory, which has the resolution of the screen and calculating the preview on that image. That is obviously the approach that should be taken. This is also the approach that is suggested in this enhancement proposal: http://bugzilla.gnome.org/show_bug.cgi?id=76096 Should we add a donate button in Bugzilla? :-) -Raphaël ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
