From: Ian C. <inc...@gm...> - 2011-01-25 05:36:50
|
it's that time of year again..... Google has just announced their Summer of code for 2011... We should really try to participate this year! the announcement is herel Google has just announced GSoC2011. http://google-opensource.blogspot.com/2011/01/google-summer-of-code-announced-at-lca.html The timeline is here: http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline Lets hear your thoughts... Thanks, Ian Caldwell |
From: Mike B. <mi...@ze...> - 2011-01-25 08:56:21
|
On Mon, 24 Jan 2011 21:36:22 -0800 Ian Caldwell <inc...@gm...> wrote: > it's that time of year again..... Google has just announced their Summer of > code for 2011... We should really try to participate this year! > the announcement is herel > Google has just announced GSoC2011. > > http://google-opensource.blogspot.com/2011/01/google-summer-of-code-announced-at-lca.html > > The timeline is here: > http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline > Lets hear your thoughts... > Thanks, > Ian Caldwell IIRC we fudged the bucket last year, so hopefully we can get better organization for it now! With that said, I can think of at least half a dozen tasks that I'd be able to mentor (successfully!) if we decide to go for it. -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! |
From: Tom H. <tom...@gm...> - 2011-01-25 09:02:33
|
And Im actually a student! :D On 25 January 2011 16:56, Mike Blumenkrantz <mi...@ze...> wrote: > On Mon, 24 Jan 2011 21:36:22 -0800 > Ian Caldwell <inc...@gm...> wrote: > >> it's that time of year again..... Google has just announced their Summer of >> code for 2011... We should really try to participate this year! >> the announcement is herel >> Google has just announced GSoC2011. >> >> http://google-opensource.blogspot.com/2011/01/google-summer-of-code-announced-at-lca.html >> >> The timeline is here: >> http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline >> Lets hear your thoughts... >> Thanks, >> Ian Caldwell > IIRC we fudged the bucket last year, so hopefully we can get better > organization for it now! > > With that said, I can think of at least half a dozen tasks that I'd be able to > mentor (successfully!) if we decide to go for it. > > -- > Mike Blumenkrantz > Zentific: NULL pointer dereferences now 50% off! > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Tom H. <tom...@pa...> - 2011-01-25 09:08:52
|
On Tue, 2011-01-25 at 17:02 +0800, Tom Haste wrote: > And Im actually a student! :D I don't think you want mike to mentor you ;P -- Tom. |
From: Mike B. <mi...@ze...> - 2011-01-25 09:11:44
|
On Tue, 25 Jan 2011 09:08:50 +0000 Tom Hacohen <tom...@pa...> wrote: > On Tue, 2011-01-25 at 17:02 +0800, Tom Haste wrote: > > And Im actually a student! :D > > I don't think you want mike to mentor you ;P > > -- > Tom. > I will be as harsh and demanding as a girlfriend after you have forgotten your anniversary. -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! |
From: Tom H. <tom...@pa...> - 2011-01-25 09:15:36
|
On Tue, 2011-01-25 at 04:11 -0500, Mike Blumenkrantz wrote: > I will be as harsh and demanding as a girlfriend after you have forgotten your > anniversary. Exactly. He'll probably also make you write doxygen docs for everything! Even internal functions. -- Tom. |
From: Mike B. <mi...@ze...> - 2011-01-25 09:20:33
|
On Tue, 25 Jan 2011 18:15:32 +0900 Tom Hacohen <tom...@pa...> wrote: > On Tue, 2011-01-25 at 04:11 -0500, Mike Blumenkrantz wrote: > > I will be as harsh and demanding as a girlfriend after you have forgotten > > your anniversary. > > Exactly. He'll probably also make you write doxygen docs for everything! > Even internal functions. > > -- > Tom. > Have you seen my internal code? It's entirely true to the spirit of EFL. Which is to say that there is no documentation, variable names are arbitrary, and there are macros on every line solely for the purpose of obfuscating the code. -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! |
From: Tom H. <tom...@gm...> - 2011-01-25 09:22:13
|
On a very very side note; considering Android has taken off, and the new 2.3 API has made working in C and C++ easier... or, and please refrain from throwing shoes at me, there is a Java-QT wrapper out there called QT Jambi than lets people write in Java with the QT toolkit... :D I wouldnt know the 1st point to writing a wrapper like that though. On 25 January 2011 17:15, Tom Hacohen <tom...@pa...> wrote: > On Tue, 2011-01-25 at 04:11 -0500, Mike Blumenkrantz wrote: >> I will be as harsh and demanding as a girlfriend after you have forgotten your >> anniversary. > > Exactly. He'll probably also make you write doxygen docs for everything! > Even internal functions. > > -- > Tom. > > |
From: Vincent T. <vt...@un...> - 2011-01-25 09:19:14
|
On Tue, 25 Jan 2011, Mike Blumenkrantz wrote: > On Mon, 24 Jan 2011 21:36:22 -0800 > Ian Caldwell <inc...@gm...> wrote: > >> it's that time of year again..... Google has just announced their Summer of >> code for 2011... We should really try to participate this year! >> the announcement is herel >> Google has just announced GSoC2011. >> >> http://google-opensource.blogspot.com/2011/01/google-summer-of-code-announced-at-lca.html >> >> The timeline is here: >> http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline >> Lets hear your thoughts... >> Thanks, >> Ian Caldwell > IIRC we fudged the bucket last year, so hopefully we can get better > organization for it now! > > With that said, I can think of at least half a dozen tasks that I'd be able to > mentor (successfully!) if we decide to go for it. And the fact that having a release soon will maybe help us. I also have several projects in mind. Vincent |
From: Mike B. <mi...@ze...> - 2011-01-25 09:25:07
|
On Tue, 25 Jan 2011 10:19:05 +0100 (CET) Vincent Torri <vt...@un...> wrote: > > > On Tue, 25 Jan 2011, Mike Blumenkrantz wrote: > > > On Mon, 24 Jan 2011 21:36:22 -0800 > > Ian Caldwell <inc...@gm...> wrote: > > > >> it's that time of year again..... Google has just announced their Summer of > >> code for 2011... We should really try to participate this year! > >> the announcement is herel > >> Google has just announced GSoC2011. > >> > >> http://google-opensource.blogspot.com/2011/01/google-summer-of-code-announced-at-lca.html > >> > >> The timeline is here: > >> http://www.google-melange.com/document/show/gsoc_program/google/gsoc2011/timeline > >> Lets hear your thoughts... > >> Thanks, > >> Ian Caldwell > > IIRC we fudged the bucket last year, so hopefully we can get better > > organization for it now! > > > > With that said, I can think of at least half a dozen tasks that I'd be able > > to mentor (successfully!) if we decide to go for it. > > And the fact that having a release soon will maybe help us. I also have > several projects in mind. > > Vincent Help coding the AI for the red rectangle boss in E-Type?/? -- Mike Blumenkrantz Zentific: NULL pointer dereferences now 50% off! |
From: Tom H. <tom...@pa...> - 2011-01-25 09:28:14
|
On Tue, 2011-01-25 at 17:22 +0800, Tom Haste wrote: > On a very very side note; considering Android has taken off, and the > new 2.3 API has made working in C and C++ easier... or, and please > refrain from throwing shoes at me, there is a Java-QT wrapper out > there called QT Jambi than lets people write in Java with the QT > toolkit... :D > > I wouldnt know the 1st point to writing a wrapper like that though. No need to hide, I'm not throwing any shoes. I'd actually like to see a Java API as well. I hate Java, but I guess people like it, and I want those people to write code using EFL :) But writing bindings is more about design and less about actual coding, I mean, there's a lot of *good* engineering to do and experience in writing API, especially in this case OOP API. -- Tom. |
From: Vincent T. <vt...@un...> - 2011-01-25 12:21:28
|
On Tue, 25 Jan 2011, Tom Hacohen wrote: > On Tue, 2011-01-25 at 17:22 +0800, Tom Haste wrote: >> On a very very side note; considering Android has taken off, and the >> new 2.3 API has made working in C and C++ easier... or, and please >> refrain from throwing shoes at me, there is a Java-QT wrapper out >> there called QT Jambi than lets people write in Java with the QT >> toolkit... :D >> >> I wouldnt know the 1st point to writing a wrapper like that though. > > No need to hide, I'm not throwing any shoes. I'd actually like to see a > Java API as well. I hate Java, but I guess people like it, and I want > those people to write code using EFL :) > > But writing bindings is more about design and less about actual coding, > I mean, there's a lot of *good* engineering to do and experience in > writing API, especially in this case OOP API. writing an android port of the EFL is easy (NDK + opengl es). Almost everything is done in the evas side. The ecore side is maybe more difficult, but easy, i think. Vincent |
From: Tom H. <tom...@pa...> - 2011-01-26 01:20:15
|
On Tue, 2011-01-25 at 13:21 +0100, Vincent Torri wrote: > writing an android port of the EFL is easy (NDK + opengl es). Almost > everything is done in the evas side. The ecore side is maybe more > difficult, but easy, i think. Not an android port, good Java bindings... -- Tom. |
From: Leif M. <lei...@gm...> - 2011-01-26 02:04:31
|
I guess OO bindings should be worth a page in Trac/Wiki as they could be partially unified with regards to c++ Maybe the more experienced devs could throw in their ideas and state (common) problems. Maybe it's possible to convert from one binding to another or use a universal description language and a generator. I'm not familiar with this topic, but am very sure that there are many many possible users of the efl out there who depend on java as a programming language/environment. BR, Leif 2011/1/26 Tom Hacohen <tom...@pa...>: > On Tue, 2011-01-25 at 13:21 +0100, Vincent Torri wrote: >> writing an android port of the EFL is easy (NDK + opengl es). Almost >> everything is done in the evas side. The ecore side is maybe more >> difficult, but easy, i think. > > Not an android port, good Java bindings... > > -- > Tom. > > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Vincent T. <vt...@un...> - 2011-01-26 06:30:17
|
Hey, I have updated the wiki: http://trac.enlightenment.org/e/wiki/Events Mainly copy/paste. It has to be filled and improved Vincent |
From: Daniel J. S. <seo...@gm...> - 2011-01-26 22:37:49
|
Hello, GSoC looks so interesting! And I was surprised to hear that enlightenment has been participating the event. I hope I knew this before when I was a student :( Anyhow, I would backup for elementary if it's ok :) Thanks. Daniel Juyung Seo (SeoZ) On Wed, Jan 26, 2011 at 3:30 PM, Vincent Torri <vt...@un...> wrote: > > Hey, > > I have updated the wiki: > > http://trac.enlightenment.org/e/wiki/Events > > Mainly copy/paste. It has to be filled and improved > > Vincent > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > |
From: Hendrik S. <hen...@go...> - 2011-01-28 13:53:27
|
Hello everybody. My name is Hendrik Siedelmann and I'm a student at the University of Stuttgart in Germany currently in my fourth year. I have worked with the efl in the past and always wanted to be more active but lacked time/motivation. I now want to change this and would like to paticipate in the GSoC. And I have an idea that went round in my head for quite some time... Image editing with the same efficiency as the rest of the efl. There is no serious image editing in efl, only interaktive stuff. However E17 is all about looks and performance and efficiency so I think some scalable image filtering capabilities that have no limitation on the image size and are usable from embedded to high end workstations is really something that's missing. There are several things wrong in how image editing is done in most programs today. As an example I'll take the following simple processing steps: crop -> denoise -> adjust brightness/contrast -> save Most image processing programs will do the processing this way: The image is decompressed from disk into memory is then filtered in multiple steps and in the full resolution and finally saved. On the way the user will try different values for each filter (propably in some preview dialog) and propably do undo and redo because for example after increasing the brightness he sees there is noise remaining in the shadows or for whatever reason. This approach has several problems: Memory usage: Memory usage will grow unlimited depending on the image size, the number of undo-steps and the number of layers. I have high resolution panoramas where memory usage in gimp exceeds 2GB with only three layers and one layer mask, undo-system completely disabled. Delays: If the user decides on a filter and filtering parameters he will want to continue but he has to wait for the filter to process the whole image which might take some time. Also if he decides that he has cropped wrong at the beginning but the other filters are ok, he will have to undo everything, crop again and then repeat all steps with all the time it takes for the filters to process the image again. Also for many filters the user will have to view the whole image (for example to see the effects of a change of brightness or contrast). So there will be huge delays to process the whole image. Waste of cpu-time: Whenever a filter is applied, all parts of the image that were rendered with the final filter parameters in some preview will be wasted. Also each undo has to throw away all processing done earlier, which will therefore have been a waste of time. There are two technics that can be utilized to solve all this problems: Graph and chunk based on-demand rendering: Every image operation is a node on a graph, which is connected to its input image(s) and has one output. There will always be one node which is connected to the global (graph)-output. Loading an image would mean creating an input node and connecting it's output to the global output. If the user wants to do an operation its input will be connected to the currently selected output and it's output will be the new graph-output. All operations on the graph will be basically instanteous, as the nodes will only need to be connected, zero operations on actual image data will be performed. The output will be created on-demand, and only for a specified area. Therefor there will be no preview in the above-mentioned sense, because it's always possible to just move to an area and let it render, the whole image only needs to be rendered when savíng. This also gets rid of the overhead of undos because if the user decides to to change a filter that is early in the filter chain he can just do so and the output can then be rerendered accordingly. While this will get rid of most useless processing this is only fast if the area the user (or some frontend) requests is small. If one wants to look at a big area (or the whole image) but at a lower scale (because screens do not have such a high resolution), then there is still the overhead of precessing the whole image for an output of much smaller size (actual output window size). Therefor the second step is: Scaled filtering: Instead of filtering at the whole scale all filters need to be able to work on a scaled down version of the image and output the same image as if applied to the full scale image and then scaling down (or a good approximation). This is trivial for some operation (like brightness contrast ...) easy for others (like blur) and difficult for some, like tonemapping or denoising. The benefit is that with scaled filtering the processing time for a specific filter graph depends only on the actual pixel count of the requested area. Low scale requests for a big part of the image but with the same actual pixel count will probably be even a bit faster compared to a small full resolution request because area filters like blur will be faster on lower scale. Of course this should also include some intelligent caching depending on the request and qraph characteristics and a bit of multithreading (easily possible by processing different chunks at the same time). Also image loaders are needed that do allow random chunk access to all supported image file formats and if possible scaled down access. Also note there are two libraries currently which implement parts of what I propose above, GEGL and libvips. However GEGL does focus on highest quality on all costs (it normally works with float as sample type!), last time I checked it was really slow and not even multithreaded. And while libvips is pretty fast, it does not include scaling and no advanced caching so it is still slow for interaktiv use and more suited for batch processing. Ok long mail. And I didn't yet go into any implementation details. What do you think? hendrik |
From: Hendrik S. <hen...@go...> - 2011-02-02 10:37:45
|
2011/1/28 Hendrik Siedelmann <hen...@go...>: > Hello everybody. > > My name is Hendrik Siedelmann and I'm a student at the University of > Stuttgart in Germany currently in my fourth year. I have worked with > the efl in the past and always wanted to be more active but lacked > time/motivation. I now want to change this and would like to > paticipate in the GSoC. And I have an idea that went round in my head > for quite some time... > > > Image editing with the same efficiency as the rest of the efl. > > There is no serious image editing in efl, only interaktive stuff. > However E17 is all about looks and performance and efficiency so I > think some scalable image filtering capabilities that have no > limitation on the image size and are usable from embedded to high end > workstations is really something that's missing. > > There are several things wrong in how image editing is done in most > programs today. > As an example I'll take the following simple processing steps: > crop -> denoise -> adjust brightness/contrast -> save > Most image processing programs will do the processing this way: > The image is decompressed from disk into memory is then filtered in > multiple steps and in the full resolution and finally saved. > On the way the user will try different values for each filter > (propably in some preview dialog) and propably do undo and redo > because for example after increasing the brightness he sees there is > noise remaining in the shadows or for whatever reason. > This approach has several problems: > > Memory usage: > Memory usage will grow unlimited depending on the image size, the > number of undo-steps and the number of layers. > I have high resolution panoramas where memory usage in gimp exceeds > 2GB with only three layers and one layer mask, undo-system completely > disabled. > > Delays: > If the user decides on a filter and filtering parameters he will want > to continue but he has to wait for the filter to process the whole > image which might take some time. > Also if he decides that he has cropped wrong at the beginning but the > other filters are ok, he will have to undo everything, crop again and > then repeat all steps with all the time it takes for the filters to > process the image again. > Also for many filters the user will have to view the whole image (for > example to see the effects of a change of brightness or contrast). So > there will be huge delays to process the whole image. > > Waste of cpu-time: > Whenever a filter is applied, all parts of the image that were > rendered with the final filter parameters in some preview will be > wasted. Also each undo has to throw away all processing done earlier, > which will therefore have been a waste of time. > > > There are two technics that can be utilized to solve all this problems: > > Graph and chunk based on-demand rendering: > Every image operation is a node on a graph, which is connected to its > input image(s) and has one output. > There will always be one node which is connected to the global > (graph)-output. Loading an image would mean creating an input node and > connecting it's output to the global output. > If the user wants to do an operation its input will be connected to > the currently selected output and it's output will be the new > graph-output. > All operations on the graph will be basically instanteous, as the > nodes will only need to be connected, zero operations on actual image > data will be performed. The output will be created on-demand, and only > for a specified area. Therefor there will be no preview in the > above-mentioned sense, because it's always possible to just move to an > area and let it render, the whole image only needs to be rendered when > savíng. > This also gets rid of the overhead of undos because if the user > decides to to change a filter that is early in the filter chain he can > just do so and the output can then be rerendered accordingly. > While this will get rid of most useless processing this is only fast > if the area the user (or some frontend) requests is small. If one > wants to look at a big area (or the whole image) but at a lower scale > (because screens do not have such a high resolution), then there is > still the overhead of precessing the whole image for an output of much > smaller size (actual output window size). > Therefor the second step is: > > Scaled filtering: > Instead of filtering at the whole scale all filters need to be able to > work on a scaled down version of the image and output the same image > as if applied to the full scale image and then scaling down (or a good > approximation). > This is trivial for some operation (like brightness contrast ...) easy > for others (like blur) and difficult for some, like tonemapping or > denoising. > The benefit is that with scaled filtering the processing time for a > specific filter graph depends only on the actual pixel count of the > requested area. Low scale requests for a big part of the image but > with the same actual pixel count will probably be even a bit faster > compared to a small full resolution request because area filters like > blur will be faster on lower scale. > > Of course this should also include some intelligent caching depending > on the request and qraph characteristics and a bit of multithreading > (easily possible by processing different chunks at the same time). > Also image loaders are needed that do allow random chunk access to all > supported image file formats and if possible scaled down access. > > Also note there are two libraries currently which implement parts of > what I propose above, GEGL and libvips. > However GEGL does focus on highest quality on all costs (it normally > works with float as sample type!), last time I checked it was really > slow and not even multithreaded. > And while libvips is pretty fast, it does not include scaling and no > advanced caching so it is still slow for interaktiv use and more > suited for batch processing. > > > Ok long mail. And I didn't yet go into any implementation details. > What do you think? > > hendrik > Guys? |
From: Ravenlock <rav...@ra...> - 2011-02-02 12:28:31
Attachments:
signature.asc
|
Hendrick, Thank you for your interest in this years GSoC. We are just now ramping up our efforts to get involved. The original post by Ian was a bit of a "Call to Arms" for the devs (and students) to measure the general GSoC temperature. You've obviously put a lot of thought into your project proposal. It looks very good. I must say you have quite a head start as compared to many students, I would expect. While we love to hear and discuss the ooportunities for you, the "official" time has not yet arrived for submission of student proposals. I think the best thing to do at this time might be to simply join us in IRC to further discuss you idea, and get some developer feedback on it. Please join us on Freenode in both #e and #edevelop. #e is a general E community channel in which you will find many users as well as the developers. Topics of discussion vary greatly. In #edevelop you will find a more developer oriented group, and the discussion is (typically) more development oriented. Please join both and jump in. Do note, if you are unfamiliar with IRC, that while there may be plenty of people in the channel, many may be idle or away from their keyboard. Please be patient when asking a question for a response. Thanks -ravenlock On 02/02/2011 04:37, Hendrik Siedelmann wrote: > 2011/1/28 Hendrik Siedelmann <hen...@go...>: >> Hello everybody. >> >> My name is Hendrik Siedelmann and I'm a student at the University of >> Stuttgart in Germany currently in my fourth year. I have worked with >> the efl in the past and always wanted to be more active but lacked >> time/motivation. I now want to change this and would like to >> paticipate in the GSoC. And I have an idea that went round in my head >> for quite some time... >> >> >> Image editing with the same efficiency as the rest of the efl. >> >> There is no serious image editing in efl, only interaktive stuff. >> However E17 is all about looks and performance and efficiency so I >> think some scalable image filtering capabilities that have no >> limitation on the image size and are usable from embedded to high end >> workstations is really something that's missing. >> >> There are several things wrong in how image editing is done in most >> programs today. >> As an example I'll take the following simple processing steps: >> crop -> denoise -> adjust brightness/contrast -> save >> Most image processing programs will do the processing this way: >> The image is decompressed from disk into memory is then filtered in >> multiple steps and in the full resolution and finally saved. >> On the way the user will try different values for each filter >> (propably in some preview dialog) and propably do undo and redo >> because for example after increasing the brightness he sees there is >> noise remaining in the shadows or for whatever reason. >> This approach has several problems: >> >> Memory usage: >> Memory usage will grow unlimited depending on the image size, the >> number of undo-steps and the number of layers. >> I have high resolution panoramas where memory usage in gimp exceeds >> 2GB with only three layers and one layer mask, undo-system completely >> disabled. >> >> Delays: >> If the user decides on a filter and filtering parameters he will want >> to continue but he has to wait for the filter to process the whole >> image which might take some time. >> Also if he decides that he has cropped wrong at the beginning but the >> other filters are ok, he will have to undo everything, crop again and >> then repeat all steps with all the time it takes for the filters to >> process the image again. >> Also for many filters the user will have to view the whole image (for >> example to see the effects of a change of brightness or contrast). So >> there will be huge delays to process the whole image. >> >> Waste of cpu-time: >> Whenever a filter is applied, all parts of the image that were >> rendered with the final filter parameters in some preview will be >> wasted. Also each undo has to throw away all processing done earlier, >> which will therefore have been a waste of time. >> >> >> There are two technics that can be utilized to solve all this problems: >> >> Graph and chunk based on-demand rendering: >> Every image operation is a node on a graph, which is connected to its >> input image(s) and has one output. >> There will always be one node which is connected to the global >> (graph)-output. Loading an image would mean creating an input node and >> connecting it's output to the global output. >> If the user wants to do an operation its input will be connected to >> the currently selected output and it's output will be the new >> graph-output. >> All operations on the graph will be basically instanteous, as the >> nodes will only need to be connected, zero operations on actual image >> data will be performed. The output will be created on-demand, and only >> for a specified area. Therefor there will be no preview in the >> above-mentioned sense, because it's always possible to just move to an >> area and let it render, the whole image only needs to be rendered when >> savíng. >> This also gets rid of the overhead of undos because if the user >> decides to to change a filter that is early in the filter chain he can >> just do so and the output can then be rerendered accordingly. >> While this will get rid of most useless processing this is only fast >> if the area the user (or some frontend) requests is small. If one >> wants to look at a big area (or the whole image) but at a lower scale >> (because screens do not have such a high resolution), then there is >> still the overhead of precessing the whole image for an output of much >> smaller size (actual output window size). >> Therefor the second step is: >> >> Scaled filtering: >> Instead of filtering at the whole scale all filters need to be able to >> work on a scaled down version of the image and output the same image >> as if applied to the full scale image and then scaling down (or a good >> approximation). >> This is trivial for some operation (like brightness contrast ...) easy >> for others (like blur) and difficult for some, like tonemapping or >> denoising. >> The benefit is that with scaled filtering the processing time for a >> specific filter graph depends only on the actual pixel count of the >> requested area. Low scale requests for a big part of the image but >> with the same actual pixel count will probably be even a bit faster >> compared to a small full resolution request because area filters like >> blur will be faster on lower scale. >> >> Of course this should also include some intelligent caching depending >> on the request and qraph characteristics and a bit of multithreading >> (easily possible by processing different chunks at the same time). >> Also image loaders are needed that do allow random chunk access to all >> supported image file formats and if possible scaled down access. >> >> Also note there are two libraries currently which implement parts of >> what I propose above, GEGL and libvips. >> However GEGL does focus on highest quality on all costs (it normally >> works with float as sample type!), last time I checked it was really >> slow and not even multithreaded. >> And while libvips is pretty fast, it does not include scaling and no >> advanced caching so it is still slow for interaktiv use and more >> suited for batch processing. >> >> >> Ok long mail. And I didn't yet go into any implementation details. >> What do you think? >> >> hendrik >> > > Guys? > > ------------------------------------------------------------------------------ > Special Offer-- Download ArcSight Logger for FREE (a $49 USD value)! > Finally, a world-class log management solution at an even better price-free! > Download using promo code Free_Logger_4_Dev2Dev. Offer expires > February 28th, so secure your free ArcSight Logger TODAY! > http://p.sf.net/sfu/arcsight-sfd2d > _______________________________________________ > enlightenment-devel mailing list > enl...@li... > https://lists.sourceforge.net/lists/listinfo/enlightenment-devel > > -- Regards, Ravenlock |
From: Hendrik S. <hen...@go...> - 2011-02-03 16:48:50
|
Hello, thank you for your answer! 2011/2/2 Ravenlock <rav...@ra...>: > Hendrick, > > Thank you for your interest in this years GSoC. We are just now ramping > up our efforts to get involved. The original post by Ian was a bit of a > "Call to Arms" for the devs (and students) to measure the general GSoC > temperature. > > You've obviously put a lot of thought into your project proposal. It > looks very good. I must say you have quite a head start as compared to > many students, I would expect. While we love to hear and discuss the > ooportunities for you, the "official" time has not yet arrived for > submission of student proposals. Hehe the moment I read gsoc I got very psyched to do something useful, so I wrote the mail, didn't look for the timeline of the whole thing so sorry if I am a bit early ;). > I think the best thing to do at this time might be to simply join us in > IRC to further discuss you idea, and get some developer feedback on it. > Please join us on Freenode in both #e and #edevelop. #e is a general E > community channel in which you will find many users as well as the > developers. Topics of discussion vary greatly. In #edevelop you will > find a more developer oriented group, and the discussion is (typically) > more development oriented. Please join both and jump in. Do note, if > you are unfamiliar with IRC, that while there may be plenty of people in > the channel, many may be idle or away from their keyboard. Please be > patient when asking a question for a response. Ok I will drop by and have a look, thanks a lot! greetings hendrik |
From: Rui M. S. S. <rm...@14...> - 2011-02-03 17:31:00
|
Em 25-01-2011 05:36, Ian Caldwell escreveu: > Lets hear your thoughts... Thread safety for ecore! Rui |
From: Vincent T. <vt...@un...> - 2011-02-03 17:33:18
|
On Thu, 3 Feb 2011, Rui Miguel Silva Seabra wrote: > Em 25-01-2011 05:36, Ian Caldwell escreveu: >> Lets hear your thoughts... > > Thread safety for ecore! for the ecore main loop ? Please no ! Vincent |
From: Cedric B. <ced...@fr...> - 2011-02-04 08:27:26
|
On Thu, Feb 3, 2011 at 6:26 PM, Rui Miguel Silva Seabra <rm...@14...> wrote: > Em 25-01-2011 05:36, Ian Caldwell escreveu: >> Lets hear your thoughts... > > Thread safety for ecore! Ecore already provide facility to handle thread, thread safety are really not needed. But Efreet mime type could really be thread safe that would be highly usefull ! -- Cedric BAIL |
From: Rui M. S. S. <rm...@14...> - 2011-02-04 09:20:02
|
Em 04-02-2011 08:27, Cedric BAIL escreveu: > On Thu, Feb 3, 2011 at 6:26 PM, Rui Miguel Silva Seabra<rm...@14...> wrote: >> Em 25-01-2011 05:36, Ian Caldwell escreveu: >>> Lets hear your thoughts... >> >> Thread safety for ecore! > > Ecore already provide facility to handle thread, thread safety are > really not needed. But Efreet mime type could really be thread safe > that would be highly usefull ! How do you make two downloads in the background at the same time, then? Rui |
From: Cedric B. <ced...@fr...> - 2011-02-04 09:36:30
|
On Fri, Feb 4, 2011 at 10:14 AM, Rui Miguel Silva Seabra <rm...@14...> wrote: > Em 04-02-2011 08:27, Cedric BAIL escreveu: >> On Thu, Feb 3, 2011 at 6:26 PM, Rui Miguel Silva Seabra<rm...@14...> >> wrote: >>> >>> Em 25-01-2011 05:36, Ian Caldwell escreveu: >>>> >>>> Lets hear your thoughts... >>> >>> Thread safety for ecore! >> >> Ecore already provide facility to handle thread, thread safety are >> really not needed. But Efreet mime type could really be thread safe >> that would be highly usefull ! > > How do you make two downloads in the background at the same time, then? ecore_con_url handle that already for you. It would be a waste of ressource to have one download per thread, as you basically just watch one fd per download. -- Cedric BAIL |