2011/1/28 Hendrik Siedelmann <[email protected]>: > 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 [email protected] https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
