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 ------------------------------------------------------------------------------ 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
