Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
Joerg Sonnenberger wrote: On Thu, Oct 30, 2008 at 09:09:55AM -0400, Jose Gonzalez wrote: Errr.. I mean in your example one *would* jpg-downscale to 32, and the software down-scale to 31. The result, with 'smooth-scaling' would be quite good. I think it is better to downscale only the *second* nearest power-of-two fraction and use full downscaling from that. That mean stay with 64 go down from that. You can test this yourself very easily right now to see the difference with your example case. Take your test 64x64 jpg image file as you want. Then, using a software-x11 evas, create two image objects. One you will load the jpg without any size load-opts, and the other with the size load-opts set to scale it to 32x32. Then, set both image objs to have smooth-scaling to true, their obj size to 31x31 and their image-fill-size to the same, and render the evas. This will smooth-scale the first one from 64 to 31 and the second from 32 to 31 (where the 32x32 will come from jpg-down-scaling), and you'll have your comparison right there. Find the right teaching school to meet your educational needs. Click to learn more. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3njBiMcP0WVpoDiiRrzq3D73GUBGxgotDlmPfug0IrYukFde/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
I wrote: ... that. if we ALWAYS scaled to the EXACT SIZE requested - we would be forced to always do it in software (as part of the generic loader) AND we now need to also add flags as to if you want raw speed (nearest sampling) or filtered scaling too - so it adds to the api, and hides and optimisation path. as such very few people use this api anyway as it requires a fairly advanced knowledge that you can pre-scale or need to scale to a given size always. i kept it simple and lefts the rest up to the user. I'm sorry Carsten, but what you're claiming here as a better load-opts pipeline and semantics in order to give potential gains for some cases needs to be put to the test. And just as importantly, we need to make sure that common-use cases aren't being hurt as a consequence. It's a confusing, complex, user-unfriendly semantics for image-size-load-options and really needs major gains across the board to justify it. Give me some real common-use cases and we'll go thru them in detail, for the main engines and various image formats, and see whether gains or losses are coming from this size-load-opts pipeline. I'll start it off here with one common-use case: Given an evas e, we want to create a thumbnail image object in e, of size w1xh1, from a given image file which is a png of size w0xh0, where w1 w0, h1 h0 but are otherwise arbitrary. We'll look at it for the cases of e being software, xrender, and gl based. We can move to the case of a jpg source next (which has certain interesting possibilities that could be explored), after we go thru this case. No chance yet to go thru this case in detail? No problem, I'll go over it so everyone can understand the process one needs to go thru for this rather common 'thumbnailing' case. For a png src file, setting image-size-load-opts has as its current semantics that: it does absolutely nothing. It is useless to even try. In order to obtain the desired thumbnail image object on the evas e (regardless of the engine for e) for png sources, one instead has to: 1. Create an image obj on e, set the image size to the desired scaled size of w0xh0 and get its data. 2. Then, you need to create a (tmp) software buffer evas of size w0xh0 and set the above data as its buffer. 3. Now, you need to add an image object to that buffer evas, load the png to it, set the obj size to the src image size of w1xh1, set the fill-size to w0xh0, and finally call a render on the buffer evas so the image obj will get drawn onto the data buffer at the scaled size of w0xh0. 4. Finally you now have your image obj on the initial evas e, with the image data at the scaled size w0xh0 that you wanted, and can get rid of the buffer evas. Ready for rendering the thumbnail or saving to another file as your need calls for. This is an absurd situation for such a common, useful case. It's considerably more inefficient than simply having size-load-opts being respected for pngs, regardless of how the scaling would be done upon load (as a secondary/alternative option, one could also consider 'save' size opts, for the case of saving to a thumbnail file). Nothing is gained with the current semantics here, regardless of engine.. quite the opposite in fact. I can give you typical losses here, not enormous but noticeable... and this is not a rare or uncommon use-case. In fact, it may well be *the* most common use-case. Now, I can go thru other use-cases in detail with you, and I can go thru them for jpg sources as well.. but I can tell you right now that in just about every conceivable case -- you will lose. You will lose even in the kinds of use-cases you mentioned where you have just the right gl driver and you're jpg-scaling to an approximate size and then gl scaling to some result. You will lose then if you have to do any mip-mapping, and even if you don't you will still eventually lose over time on scaled re-draws (vs. a one-time scale and then copy-renders). How much more do you want to go over this? Click to become a master chef, own a restaurant and make millions. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m4pCm8tfNPOnBHbvfzxNIobkiSWZBRBZQyracA6bgUtIYsg/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
... that. if we ALWAYS scaled to the EXACT SIZE requested - we would be forced to always do it in software (as part of the generic loader) AND we now need to also add flags as to if you want raw speed (nearest sampling) or filtered scaling too - so it adds to the api, and hides and optimisation path. as such very few people use this api anyway as it requires a fairly advanced knowledge that you can pre-scale or need to scale to a given size always. i kept it simple and lefts the rest up to the user. I'm sorry Carsten, but what you're claiming here as a better load-opts pipeline and semantics in order to give potential gains for some cases needs to be put to the test. And just as importantly, we need to make sure that common-use cases aren't being hurt as a consequence. It's a confusing, complex, user-unfriendly semantics for image-size-load-options and really needs major gains across the board to justify it. Give me some real common-use cases and we'll go thru them in detail, for the main engines and various image formats, and see whether gains or losses are coming from this size-load-opts pipeline. I'll start it off here with one common-use case: Given an evas e, we want to create a thumbnail image object in e, of size w1xh1, from a given image file which is a png of size w0xh0, where w1 w0, h1 h0 but are otherwise arbitrary. We'll look at it for the cases of e being software, xrender, and gl based. We can move to the case of a jpg source next (which has certain interesting possibilities that could be explored), after we go thru this case. No chance yet to go thru this case in detail? No problem, I'll go over it so everyone can understand the process one needs to go thru for this rather common 'thumbnailing' case. For a png src file, setting image-size-load-opts has as its current semantics that: it does absolutely nothing. It is useless to even try. In order to obtain the desired thumbnail image object on the evas e (regardless of the engine for e) for png sources, one instead has to: 1. Create an image obj on e, set the image size to the desired scaled size of w0xh0 and get its data. 2. Then, you need to create a (tmp) software buffer evas of size w0xh0 and set the above data as its buffer. 3. Now, you need to add an image object to that buffer evas, load the png to it, set the obj size to the src image size of w1xh1, set the fill-size to w0xh0, and finally call a render on the buffer evas so the image obj will get drawn onto the data buffer at the scaled size of w0xh0. 4. Finally you now have your image obj on the initial evas e, with the image data at the scaled size w0xh0 that you wanted, and can get rid of the buffer evas. Ready for rendering the thumbnail or saving to another file as your need calls for. Oops, got my 0 and 1 indexes reversed here. This is an absurd situation for such a common, useful case. It's considerably more inefficient than simply having size-load-opts being respected for pngs, regardless of how the scaling would be done upon load (as a secondary/alternative option, one could also consider 'save' size opts, for the case of saving to a thumbnail file). Nothing is gained with the current semantics here, regardless of engine.. quite the opposite in fact. I can give you typical losses here, not enormous but noticeable... and this is not a rare or uncommon use-case. In fact, it may well be *the* most common use-case. Now, I can go thru other use-cases in detail with you, and I can go thru them for jpg sources as well.. but I can tell you right now that in just about every conceivable case -- you will lose. You will lose even in the kinds of use-cases you mentioned where you have just the right gl driver and you're jpg-scaling to an approximate size and then gl scaling to some result. You will lose then if you have to do any mip-mapping, and even if you don't you will still eventually lose over time on scaled re-draws (vs. a one-time scale and then copy-renders). How much more do you want to go over this? And btw, why would one be so foolish, when implementing the size-load-opts down-scaling for jpgs, that they would simply software down-scale all the way from the src size down to the load-opt size? Why would they not do just what you're suggesting people do themselves - find the nearest power-of-2 fraction, jpg-downscale to that, and then software down-scale the rest of the way? :) Click for free info on online degrees and make up to $150K/ year. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nlXFfGumsyJmZcJWsxvUVgovMahMvFQwn927ROnq7XhIy0c/ - This SF.Net email is sponsored
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
On Thu, Oct 30, 2008 at 7:05 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: And btw, why would one be so foolish, when implementing the size-load-opts down-scaling for jpgs, that they would simply software down-scale all the way from the src size down to the load-opt size? Why would they not do just what you're suggesting people do themselves - find the nearest power-of-2 fraction, jpg-downscale to that, and then software down-scale the rest of the way? :) Jose, all these 3 huge mails from you resume into a single api change: add a force flag to parameters, that's it. This last mail that request users to do power-of-2 on their side is as bad as you say it's to create a temporary canvas, it requires too much knowledge on user size, in this case require user to know about JPEG properties. PS: try to sent one single mail with all contents, the more compressed the better, it's hard to keep up with tons of mail with huge replies to themselves. Often I just lack motivation to finish reading your mails, I need to postpone reading to sometime I have more free time and I really loose lots of time trying to find the useful bits among all of them (there is always good stuff). Regards, -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
Gustavo wrote: On Thu, Oct 30, 2008 at 7:05 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: And btw, why would one be so foolish, when implementing the size-load-opts down-scaling for jpgs, that they would simply software down-scale all the way from the src size down to the load-opt size? Why would they not do just what you're suggesting people do themselves - find the nearest power-of-2 fraction, jpg-downscale to that, and then software down-scale the rest of the way? :) Jose, all these 3 huge mails from you resume into a single api change: add a force flag to parameters, that's it. This last mail that request users to do power-of-2 on their side is as bad as you say it's to create a temporary canvas, it requires too much knowledge on user size, in this case require user to know about JPEG properties. No, no. Quite the opposite. It's the current situation that demands people do this. What I'm saying is that the jpg loader should do this itself, ie. respect image size load-opts and implement it so that it does this. PS: try to sent one single mail with all contents, the more compressed the better, it's hard to keep up with tons of mail with huge replies to themselves. Often I just lack motivation to finish reading your mails, I need to postpone reading to sometime I have more free time and I really loose lots of time trying to find the useful bits among all of them (there is always good stuff). Who me? Write multiple, lengthy, rambling emails as my thoughts move along and I get the chance to actually write... :) I'll try Gustavo, I'll try. :) Click for free information on accounting careers, $150 hour potential. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3l691xVNZYlGjzUK9GjJRuV1drXcBJoYCHM2f0y3Z6gaGS64/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
On Thu, Oct 30, 2008 at 9:51 AM, Nicolas Aguirre [EMAIL PROTECTED] wrote: 2008/10/30 Jose Gonzalez [EMAIL PROTECTED] This last mail that request users to do power-of-2 on their side is as bad as you say it's to create a temporary canvas, it requires too much knowledge on user size, in this case require user to know about JPEG properties. No, no. Quite the opposite. It's the current situation that demands people do this. What I'm saying is that the jpg loader should do this itself, ie. respect image size load-opts and implement it so that it does this. In enna, I load directory of jpeg pictures. These pictures are swallow in edje group and each edje group are added in a box smart object. For example this pictures are 3648x2736. Here is my code to load one picture : o_edje = edje_object_add(e); edje_object_file_set(o_edje, enna_config_theme_get(), enna/picture/item); o_pict = evas_object_image_add(e); evas_object_image_file_set(o_pict, filename, NULL); evas_object_image_size_get(o_pict, w, h); ratio = (float)w / float(h); oh = 200; ow = oh * ratio; evas_object_image_load_size_set(o_pict, ow, oh); evas_object_resize(o_pict, ow, oh); evas_object_image_preload(o_pict, 0); edje_extern_object_min_size_set(o_edje, ow, oh); edje_extern_object_aspect_set(o_edje, EDJE_ASPECT_CONTROL_BOTH, ratio, ratio); edje_object_part_swallow(o_edje, enna.swallow.picture, o_pict); evas_object_show(o_pict); It seems that pictures are load and display faster if i use the evas_object_image_load_size_set api and the preload. But if I understand this thread, I should have better results if I use power of two dimensions for the load options, and after that resize image object to the dimension I need (here w = 200 and h = w * ratio) ? load size will automatically work to the nearest larger or equal power of two size. as for resize, yes, as raster said you will end with images that are not w=200, so if you do not resize them later you will do the resize for every frame in animations and so (evas still does not auto-cache scale results). -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
2008/10/30 Jose Gonzalez [EMAIL PROTECTED] This last mail that request users to do power-of-2 on their side is as bad as you say it's to create a temporary canvas, it requires too much knowledge on user size, in this case require user to know about JPEG properties. No, no. Quite the opposite. It's the current situation that demands people do this. What I'm saying is that the jpg loader should do this itself, ie. respect image size load-opts and implement it so that it does this. In enna, I load directory of jpeg pictures. These pictures are swallow in edje group and each edje group are added in a box smart object. For example this pictures are 3648x2736. Here is my code to load one picture : o_edje = edje_object_add(e); edje_object_file_set(o_edje, enna_config_theme_get(), enna/picture/item); o_pict = evas_object_image_add(e); evas_object_image_file_set(o_pict, filename, NULL); evas_object_image_size_get(o_pict, w, h); ratio = (float)w / float(h); oh = 200; ow = oh * ratio; evas_object_image_load_size_set(o_pict, ow, oh); evas_object_resize(o_pict, ow, oh); evas_object_image_preload(o_pict, 0); edje_extern_object_min_size_set(o_edje, ow, oh); edje_extern_object_aspect_set(o_edje, EDJE_ASPECT_CONTROL_BOTH, ratio, ratio); edje_object_part_swallow(o_edje, enna.swallow.picture, o_pict); evas_object_show(o_pict); It seems that pictures are load and display faster if i use the evas_object_image_load_size_set api and the preload. But if I understand this thread, I should have better results if I use power of two dimensions for the load options, and after that resize image object to the dimension I need (here w = 200 and h = w * ratio) ? -- Nicolas Aguirre Mail: [EMAIL PROTECTED] Web: http://www.digital-corner.org - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
On Thu, Oct 30, 2008 at 05:05:37AM -0400, Jose Gonzalez wrote: And btw, why would one be so foolish, when implementing the size-load-opts down-scaling for jpgs, that they would simply software down-scale all the way from the src size down to the load-opt size? Why would they not do just what you're suggesting people do themselves - find the nearest power-of-2 fraction, jpg-downscale to that, and then software down-scale the rest of the way? :) Scaling to the nearest power-of-2 is certainly asking for horrible resuls. I also don't think the hardware acceleration will buy you much, transferr overhead is quite high and not-so-current hardware is huge limitations on maximum sizes it can handle. E.g. the given example wouldn't work with most IGD chips. Joerg PS: I thought common policy was still line wrapping after 72 chars... - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
On Thu, Oct 30, 2008 at 9:06 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: Gustavo wrote: On Thu, Oct 30, 2008 at 7:05 AM, Jose Gonzalez [EMAIL PROTECTED] wrote: And btw, why would one be so foolish, when implementing the size-load-opts down-scaling for jpgs, that they would simply software down-scale all the way from the src size down to the load-opt size? Why would they not do just what you're suggesting people do themselves - find the nearest power-of-2 fraction, jpg-downscale to that, and then software down-scale the rest of the way? :) Jose, all these 3 huge mails from you resume into a single api change: add a force flag to parameters, that's it. This last mail that request users to do power-of-2 on their side is as bad as you say it's to create a temporary canvas, it requires too much knowledge on user size, in this case require user to know about JPEG properties. No, no. Quite the opposite. It's the current situation that demands people do this. What I'm saying is that the jpg loader should do this itself, ie. respect image size load-opts and implement it so that it does this. You both have a point, that's why I say the solution is to add a force flag. Force=1 is what you want, Force=0 is what raster want, simple. PS: try to sent one single mail with all contents, the more compressed the better, it's hard to keep up with tons of mail with huge replies to themselves. Often I just lack motivation to finish reading your mails, I need to postpone reading to sometime I have more free time and I really loose lots of time trying to find the useful bits among all of them (there is always good stuff). Who me? Write multiple, lengthy, rambling emails as my thoughts move along and I get the chance to actually write... :) I'll try Gustavo, I'll try. :) Save a draft for at least 12hours, then review, edit and mail the final version... It's rare you to get a reply before that time, so it will be about the same (you'll not loose some replies or so). :-) -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
Gustavo wrote: On Thu, Oct 30, 2008 at 9:51 AM, Nicolas Aguirre [EMAIL PROTECTED] wrote: 2008/10/30 Jose Gonzalez [EMAIL PROTECTED] This last mail that request users to do power-of-2 on their side is as bad as you say it's to create a temporary canvas, it requires too much knowledge on user size, in this case require user to know about JPEG properties. No, no. Quite the opposite. It's the current situation that demands people do this. What I'm saying is that the jpg loader should do this itself, ie. respect image size load-opts and implement it so that it does this. In enna, I load directory of jpeg pictures. These pictures are swallow in edje group and each edje group are added in a box smart object. For example this pictures are 3648x2736. Here is my code to load one picture : o_edje = edje_object_add(e); edje_object_file_set(o_edje, enna_config_theme_get(), enna/picture/item); o_pict = evas_object_image_add(e); evas_object_image_file_set(o_pict, filename, NULL); evas_object_image_size_get(o_pict, w, h); ratio = (float)w / float(h); oh = 200; ow = oh * ratio; evas_object_image_load_size_set(o_pict, ow, oh); evas_object_resize(o_pict, ow, oh); evas_object_image_preload(o_pict, 0); edje_extern_object_min_size_set(o_edje, ow, oh); edje_extern_object_aspect_set(o_edje, EDJE_ASPECT_CONTROL_BOTH, ratio, ratio); edje_object_part_swallow(o_edje, enna.swallow.picture, o_pict); evas_object_show(o_pict); It seems that pictures are load and display faster if i use the evas_object_image_load_size_set api and the preload. But if I understand this thread, I should have better results if I use power of two dimensions for the load options, and after that resize image object to the dimension I need (here w = 200 and h = w * ratio) ? load size will automatically work to the nearest larger or equal power of two size. as for resize, yes, as raster said you will end with images that are not w=200, so if you do not resize them later you will do the resize for every frame in animations and so (evas still does not auto-cache scale results). I would reply to this myself, but I need to wait 12 hrs. ;) PS. While we're on this topic, let me quickly add some further nonsense regarding load options in general. I would actually go as far as to consider letting image borders be considered, and eventually when/if object transforms are done (not image fill-transforms), I'd consider these as well. It might also be useful to look into having these be represented in edje/edc in a comprehensive way.. possibly even applied to edje groups as a whole. Find the right teaching school to meet your educational needs. Click to learn more. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3njBiRzXr1lpJi743NtRu9dPSQgXnrkaBx3sh5bURz5Jt2UE/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
On Thu, Oct 30, 2008 at 08:23:19AM -0400, Jose Gonzalez wrote: Scaling to the nearest power-of-2 is certainly asking for horrible resuls. I also don't think the hardware acceleration will buy you much, transferr overhead is quite high and not-so-current hardware is huge limitations on maximum sizes it can handle. E.g. the given example wouldn't work with most IGD chips. Power-of-2 *fraction*, ie. 1/2, 1/4, etc. of the original size. Sure, but at least if you use any type of non-trivial interpolation algorithm to compute the final non-power-of-2-fraction, you get inferior results if you cut down to the next larger power-of-2-fraction first. Consider you want to scale down from 64 pixel to 31 pixel -- you throw a lot of information away by scaling down to 32 pixel first, even though that is cheap. Joerg - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
Joerg Sonnenberger wrote: On Thu, Oct 30, 2008 at 08:23:19AM -0400, Jose Gonzalez wrote: Scaling to the nearest power-of-2 is certainly asking for horrible resuls. I also don't think the hardware acceleration will buy you much, transferr overhead is quite high and not-so-current hardware is huge limitations on maximum sizes it can handle. E.g. the given example wouldn't work with most IGD chips. Power-of-2 *fraction*, ie. 1/2, 1/4, etc. of the original size. Sure, but at least if you use any type of non-trivial interpolation algorithm to compute the final non-power-of-2-fraction, you get inferior results if you cut down to the next larger power-of-2-fraction first. Consider you want to scale down from 64 pixel to 31 pixel -- you throw a lot of information away by scaling down to 32 pixel first, even though that is cheap. The semantics isn't entirely up for grabs. Either we choose the nearest power-of-2 fraction which is greater than the desired, or nearest period. Usually, for this application one would take the former (though at the moment I don't recall what Carsten threw in there), and in your example that would mean no jpg-scaling and simply software down-scale to 31. Click here to learn more about nursing jobs. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3nEvqmZOLkAWwQAYSvo27S4bivdhr74iMV0bWjas2KUksPji/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
Scaling to the nearest power-of-2 is certainly asking for horrible resuls. I also don't think the hardware acceleration will buy you much, transferr overhead is quite high and not-so-current hardware is huge limitations on maximum sizes it can handle. E.g. the given example wouldn't work with most IGD chips. Power-of-2 *fraction*, ie. 1/2, 1/4, etc. of the original size. Sure, but at least if you use any type of non-trivial interpolation algorithm to compute the final non-power-of-2-fraction, you get inferior results if you cut down to the next larger power-of-2-fraction first. Consider you want to scale down from 64 pixel to 31 pixel -- you throw a lot of information away by scaling down to 32 pixel first, even though that is cheap. The semantics isn't entirely up for grabs. Either we choose the nearest power-of-2 fraction which is greater than the desired, or nearest period. Usually, for this application one would take the former (though at the moment I don't recall what Carsten threw in there), and in your example that would mean no jpg-scaling and simply software down-scale to 31. Errr.. I mean in your example one *would* jpg-downscale to 32, and the software down-scale to 31. The result, with 'smooth-scaling' would be quite good. Need to take Gustavo's 12 hr. advice... :) Click to become an artist and quit your boring job. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3mzjsJ8nFkEvwwtvjjwTGg6ELR7S8cOVhATcPDJdfD7bDVSE/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
On Thu, Oct 30, 2008 at 09:09:55AM -0400, Jose Gonzalez wrote: Errr.. I mean in your example one *would* jpg-downscale to 32, and the software down-scale to 31. The result, with 'smooth-scaling' would be quite good. I think it is better to downscale only the *second* nearest power-of-two fraction and use full downscaling from that. That mean stay with 64 go down from that. Joerg - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
in case your have not subscribed to the xcd ML Vincent -- Forwarded message -- Date: Wed, 29 Oct 2008 12:52:53 +0100 From: Philip Van Hoof [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Prototype thumbnailer now has a Epeg plugin On Mon, 2008-10-27 at 13:38 +0100, Philip Van Hoof wrote: Hi there, I implemented a plugin that uses Carsten's Epeg library to create thumbnails of Jpeg files[3]. This EPeg support made me conclude that the specialized thumbnailers do need a URI-scheme support registration. But not for tackling the VFS issue. The reason is that you can have a thumbnailer R that doesn't support remote URI schemes, and you can have a thumbnailer K, supporting the same MIME types as R, that does support remote URI schemes. For example the EPeg thumbnailer doesn't support remote URIs, because the library EPeg only works with local paths. The GdkPixbuf based thumbnailer supports both remote and local URIs, as the GdkPixbuf based thumbnailer uses GIO and GInputStream to load the image from. This means that the generic thumbnailer needs to elect the GdkPixbuf based one in case of a URI-scheme that is not file and a MIME type that is image/jpeg. However In case the URI-scheme is file and the MIME typs is image/jpeg, it instead needs to elect the EPeg based thumbnailer. At the Registering your thumbnailer section [1] I added support for this use-case to the specification. $XDG_DATA_DIRS/thumbnailers/com.rasterman.Thumbnailer.service: [D-BUS Thumbnailer] Name=com.rasterman.Thumbnailer MimeTypes=image/jpeg Comment=The great EPeg thumbnailer UriSchemes=file $XDG_DATA_DIRS/thumbnailers/org.gnome.Thumbnailer.service: [D-BUS Thumbnailer] Name=org.gnome.Thumbnailer MimeTypes=image/jpeg;image/png;... Comment=The also great GNOME thumbnailer, but less fast than EPeg UriSchemes=file;sftp;ftp;http;smb;nfs;dav To make sure that the EPeg one is elected for local files that are JPegs you either make sure com.rasterman.Thumbnailer.service's mtime is more recent than org.gnome.Thumbnailer.service and/or you write an overrides: $XDG_DATA_DIRS/thumbnailers/overrides: [file-image/jpeg] Name=com.rasterman.Thumbnailer ps. The prototype [2] is adapted for this. [1] http://live.gnome.org/ThumbnailerSpec#head-2a0cd233f583dcde553c0a8b5150fa737f73cdce [2] https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-thumbnail/ hf -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ xdg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xdg - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
I wonder if it's not better to make their thumbnailer suck less (dump jpg thumbnailer, use code from EPEG or Evas) instead of adding all this complexity. And still we cannot select custom thumbnail sizes, so useless for media centers and lots of fancy systems that might choose something different than 2-power numbers like square 128 and 256. On Wed, Oct 29, 2008 at 9:55 AM, Vincent Torri [EMAIL PROTECTED] wrote: in case your have not subscribed to the xcd ML Vincent -- Forwarded message -- Date: Wed, 29 Oct 2008 12:52:53 +0100 From: Philip Van Hoof [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Prototype thumbnailer now has a Epeg plugin On Mon, 2008-10-27 at 13:38 +0100, Philip Van Hoof wrote: Hi there, I implemented a plugin that uses Carsten's Epeg library to create thumbnails of Jpeg files[3]. This EPeg support made me conclude that the specialized thumbnailers do need a URI-scheme support registration. But not for tackling the VFS issue. The reason is that you can have a thumbnailer R that doesn't support remote URI schemes, and you can have a thumbnailer K, supporting the same MIME types as R, that does support remote URI schemes. For example the EPeg thumbnailer doesn't support remote URIs, because the library EPeg only works with local paths. The GdkPixbuf based thumbnailer supports both remote and local URIs, as the GdkPixbuf based thumbnailer uses GIO and GInputStream to load the image from. This means that the generic thumbnailer needs to elect the GdkPixbuf based one in case of a URI-scheme that is not file and a MIME type that is image/jpeg. However In case the URI-scheme is file and the MIME typs is image/jpeg, it instead needs to elect the EPeg based thumbnailer. At the Registering your thumbnailer section [1] I added support for this use-case to the specification. $XDG_DATA_DIRS/thumbnailers/com.rasterman.Thumbnailer.service: [D-BUS Thumbnailer] Name=com.rasterman.Thumbnailer MimeTypes=image/jpeg Comment=The great EPeg thumbnailer UriSchemes=file $XDG_DATA_DIRS/thumbnailers/org.gnome.Thumbnailer.service: [D-BUS Thumbnailer] Name=org.gnome.Thumbnailer MimeTypes=image/jpeg;image/png;... Comment=The also great GNOME thumbnailer, but less fast than EPeg UriSchemes=file;sftp;ftp;http;smb;nfs;dav To make sure that the EPeg one is elected for local files that are JPegs you either make sure com.rasterman.Thumbnailer.service's mtime is more recent than org.gnome.Thumbnailer.service and/or you write an overrides: $XDG_DATA_DIRS/thumbnailers/overrides: [file-image/jpeg] Name=com.rasterman.Thumbnailer ps. The prototype [2] is adapted for this. [1] http://live.gnome.org/ThumbnailerSpec#head-2a0cd233f583dcde553c0a8b5150fa737f73cdce [2] https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-thumbnail/ hf -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ xdg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xdg - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel -- Gustavo Sverzut Barbieri http://profusion.mobi embedded systems -- MSN: [EMAIL PROTECTED] Skype: gsbarbieri Mobile: +55 (19) 9225-2202 - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
Gustavo wrote: I wonder if it's not better to make their thumbnailer suck less (dump jpg thumbnailer, use code from EPEG or Evas) instead of adding all this complexity. And still we cannot select custom thumbnail sizes, so useless for media centers and lots of fancy systems that might choose something different than 2-power numbers like square 128 and 256. And this reminds me of the argument Carsten and I had over evas image size-load-options, where I felt it useless and confusing to have such options that only worked sometimes for some formats some sizes.. rather than always for all formats and sizes. On Wed, Oct 29, 2008 at 9:55 AM, Vincent Torri [EMAIL PROTECTED] wrote: in case your have not subscribed to the xcd ML Vincent -- Forwarded message -- Date: Wed, 29 Oct 2008 12:52:53 +0100 From: Philip Van Hoof [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Prototype thumbnailer now has a Epeg plugin On Mon, 2008-10-27 at 13:38 +0100, Philip Van Hoof wrote: Hi there, I implemented a plugin that uses Carsten's Epeg library to create thumbnails of Jpeg files[3]. This EPeg support made me conclude that the specialized thumbnailers do need a URI-scheme support registration. But not for tackling the VFS issue. The reason is that you can have a thumbnailer R that doesn't support remote URI schemes, and you can have a thumbnailer K, supporting the same MIME types as R, that does support remote URI schemes. For example the EPeg thumbnailer doesn't support remote URIs, because the library EPeg only works with local paths. The GdkPixbuf based thumbnailer supports both remote and local URIs, as the GdkPixbuf based thumbnailer uses GIO and GInputStream to load the image from. This means that the generic thumbnailer needs to elect the GdkPixbuf based one in case of a URI-scheme that is not file and a MIME type that is image/jpeg. However In case the URI-scheme is file and the MIME typs is image/jpeg, it instead needs to elect the EPeg based thumbnailer. At the Registering your thumbnailer section [1] I added support for this use-case to the specification. $XDG_DATA_DIRS/thumbnailers/com.rasterman.Thumbnailer.service: [D-BUS Thumbnailer] Name=com.rasterman.Thumbnailer MimeTypes=image/jpeg Comment=The great EPeg thumbnailer UriSchemes=file $XDG_DATA_DIRS/thumbnailers/org.gnome.Thumbnailer.service: [D-BUS Thumbnailer] Name=org.gnome.Thumbnailer MimeTypes=image/jpeg;image/png;... Comment=The also great GNOME thumbnailer, but less fast than EPeg UriSchemes=file;sftp;ftp;http;smb;nfs;dav To make sure that the EPeg one is elected for local files that are JPegs you either make sure com.rasterman.Thumbnailer.service's mtime is more recent than org.gnome.Thumbnailer.service and/or you write an overrides: $XDG_DATA_DIRS/thumbnailers/overrides: [file-image/jpeg] Name=com.rasterman.Thumbnailer ps. The prototype [2] is adapted for this. [1] http://live.gnome.org/ThumbnailerSpec#head-2a0cd233f583dcde553c0a8b5150fa737f73cdce [2] https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-thumbnail/ hf -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ xdg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xdg - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel Click to receive credit card help and get out of debt fast. http://thirdpartyoffers.juno.com/TGL2141/fc/Ioyw6i3m2DVIliupxPqMXcSVUO7zUHAynXq9mPlmv8GaYqV53OaIgs/ - This SF.Net email is sponsored by the Moblin Your Move Developer's challenge Build the coolest Linux based applications with Moblin SDK win great prizes Grand prize is a trip for two to an Open Source event anywhere in the world http://moblin-contest.org/redirect.php?banner_id=100url=/ ___ enlightenment-devel mailing list enlightenment-devel@lists.sourceforge.net https://lists.sourceforge.net/lists/listinfo/enlightenment-devel
Re: [E-devel] Prototype thumbnailer now has a Epeg plugin (fwd)
On Wed, 29 Oct 2008 11:06:45 -0400 Jose Gonzalez [EMAIL PROTECTED] babbled: Gustavo wrote: I wonder if it's not better to make their thumbnailer suck less (dump jpg thumbnailer, use code from EPEG or Evas) instead of adding all this complexity. And still we cannot select custom thumbnail sizes, so useless for media centers and lots of fancy systems that might choose something different than 2-power numbers like square 128 and 256. And this reminds me of the argument Carsten and I had over evas image size-load-options, where I felt it useless and confusing to have such options that only worked sometimes for some formats some sizes.. rather than always for all formats and sizes. because then you'd be stuck with the non for free resizing being done in software. let me give u an example. you have a photo: 3200x2400. you have a screen 640x480. you have an acceleration chip (let's say gl). you can LOAD the jpeg for less cost than a full load of all 3200x2400 (faster) if you scale ON LOAD. it can load 5 or 10 times faster. BUT the jpeg format has limits. you can only get a scale for free with 1/2, 1/4 or 1/8 size. you get good quality because the jpeg is encoded in the frequency domain (DCT) and all it does is throw out higher frequencies so you get a filtered scaling anyway. for free. this means you would choose to load at 800x600 (1/4). this is higher than you need, but better than 400x300. NOW your graphics accelerator does the rest and scales to 640x480. you get to use the engine's native scaling mechanisms after that. if we ALWAYS scaled to the EXACT SIZE requested - we would be forced to always do it in software (as part of the generic loader) AND we now need to also add flags as to if you want raw speed (nearest sampling) or filtered scaling too - so it adds to the api, and hides and optimisation path. as such very few people use this api anyway as it requires a fairly advanced knowledge that you can pre-scale or need to scale to a given size always. i kept it simple and lefts the rest up to the user. On Wed, Oct 29, 2008 at 9:55 AM, Vincent Torri [EMAIL PROTECTED] wrote: in case your have not subscribed to the xcd ML Vincent -- Forwarded message -- Date: Wed, 29 Oct 2008 12:52:53 +0100 From: Philip Van Hoof [EMAIL PROTECTED] To: [EMAIL PROTECTED] Subject: Re: Prototype thumbnailer now has a Epeg plugin On Mon, 2008-10-27 at 13:38 +0100, Philip Van Hoof wrote: Hi there, I implemented a plugin that uses Carsten's Epeg library to create thumbnails of Jpeg files[3]. This EPeg support made me conclude that the specialized thumbnailers do need a URI-scheme support registration. But not for tackling the VFS issue. The reason is that you can have a thumbnailer R that doesn't support remote URI schemes, and you can have a thumbnailer K, supporting the same MIME types as R, that does support remote URI schemes. For example the EPeg thumbnailer doesn't support remote URIs, because the library EPeg only works with local paths. The GdkPixbuf based thumbnailer supports both remote and local URIs, as the GdkPixbuf based thumbnailer uses GIO and GInputStream to load the image from. This means that the generic thumbnailer needs to elect the GdkPixbuf based one in case of a URI-scheme that is not file and a MIME type that is image/jpeg. However In case the URI-scheme is file and the MIME typs is image/jpeg, it instead needs to elect the EPeg based thumbnailer. At the Registering your thumbnailer section [1] I added support for this use-case to the specification. $XDG_DATA_DIRS/thumbnailers/com.rasterman.Thumbnailer.service: [D-BUS Thumbnailer] Name=com.rasterman.Thumbnailer MimeTypes=image/jpeg Comment=The great EPeg thumbnailer UriSchemes=file $XDG_DATA_DIRS/thumbnailers/org.gnome.Thumbnailer.service: [D-BUS Thumbnailer] Name=org.gnome.Thumbnailer MimeTypes=image/jpeg;image/png;... Comment=The also great GNOME thumbnailer, but less fast than EPeg UriSchemes=file;sftp;ftp;http;smb;nfs;dav To make sure that the EPeg one is elected for local files that are JPegs you either make sure com.rasterman.Thumbnailer.service's mtime is more recent than org.gnome.Thumbnailer.service and/or you write an overrides: $XDG_DATA_DIRS/thumbnailers/overrides: [file-image/jpeg] Name=com.rasterman.Thumbnailer ps. The prototype [2] is adapted for this. [1] http://live.gnome.org/ThumbnailerSpec#head-2a0cd233f583dcde553c0a8b5150fa737f73cdce [2] https://stage.maemo.org/svn/maemo/projects/haf/trunk/hildon-thumbnail/ hf -- Philip Van Hoof, freelance software developer home: me at pvanhoof dot be gnome: pvanhoof at gnome dot org http://pvanhoof.be/blog http://codeminded.be ___ xdg mailing list [EMAIL PROTECTED] http://lists.freedesktop.org/mailman/listinfo/xdg
