[Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
Hi Nicolas, This is my first forum of any kind so please forgive me for any mistake. i m a student and interested in gsoc project:Fast Adaptive Resampler Tailored For Transformations Which Mostly Downsample I have read the requirements properly for this project which also includes jacobian transformation,box filtering algorithm and bilinear resampling.But i am having some problem in relating all these in one algorithm.Please guide me.Also I would like to know the status of this project progress. Thanks, -- Rahul ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
peter sikking wrote: that is why we will have _one_ setting in the View menu, that sets the overall strategy to either one-window or multi-window. all further behaviour follows from that. There could be more settings in the preferences though. Couldn't there? looking forward to that version ;) -- View this message in context: http://www.nabble.com/Dockable-Dialogs-Should-be-Dockable-Everywhere-tp21279278p22430291.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
hOSHI wrote: peter sikking wrote: that is why we will have _one_ setting in the View menu, that sets the overall strategy to either one-window or multi-window. all further behaviour follows from that. There could be more settings in the preferences though. Couldn't there? it is good design practice to avoid that like the plague. --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
peter sikking wrote: it is good design practice to avoid that like the plague. It's a good practice to avoid user comfort through customization? Did i get that right? -- View this message in context: http://www.nabble.com/Dockable-Dialogs-Should-be-Dockable-Everywhere-tp21279278p22430746.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Von: hOSHI mutenho...@gmail.com Alexandre Prokoudine wrote: Customization is overrated. Then why can i define my own window and statusbar format in gimp? ;] There have been comments that there's too much information shown there, and most of it isn't needed, so imagine what might change in that regard... :) Regards, Michael -- Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a -- Computer Bild Tarifsieger! GMX FreeDSL - Telefonanschluss + DSL für nur 17,95 Euro/mtl.!* http://dsl.gmx.de/?ac=OM.AD.PD003K11308T4569a ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Michael Schumacher wrote: There have been comments that there's too much information shown there, and most of it isn't needed, so imagine what might change in that regard... :) i like customization. As long as it is well structured (and maybe accessible only if advanced options is checked) in a professional prog like Gimp there is more of a need to fulfill personal needs than in a simple browser or a imageviewer. i often changed programs i used, because i couldn't get it do to what i want or need. so customization isn't always bad, i guess it depends on the intended audience. -- View this message in context: http://www.nabble.com/Dockable-Dialogs-Should-be-Dockable-Everywhere-tp21279278p22431423.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
On Tue, Mar 10, 2009 at 1:21 PM, hOSHI wrote: (and maybe accessible only if advanced options is checked) Which is also usually considered as bad practice. Sorry :) Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Alexandre Prokoudine wrote: Which is also usually considered as bad practice. Sorry :) considered by whom? in a professional tool there need to be some settings. photoshop/3ds max/blender/maya/openoffice(grin) they just need to be structured right. maybe settings that are not so important should go for important ones. In that i would agree. -- View this message in context: http://www.nabble.com/Dockable-Dialogs-Should-be-Dockable-Everywhere-tp21279278p22431626.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
I think it's not about customization or not. Is about avoiding a cluttered prefs menu with gazillions of options and provide smart ways to customize instead. Look at this for instance: http://www.youtube.com/watch?v=v5IjbClO8Sk (the upcoming Blender 2.5) There you have an example of a highly customizable environment without the need of marking checkboxes in the preferences section. Gez ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Guillermo Espertino wrote: I think it's not about customization or not. Is about avoiding a cluttered prefs menu with gazillions of options and provide smart ways to customize instead. Look at this for instance: http://www.youtube.com/watch?v=v5IjbClO8Sk (the upcoming Blender 2.5) There you have an example of a highly customizable environment without the need of marking checkboxes in the preferences section. that is an example of just put it as you like it as you go along. although the pop-up menu to set the content of the areas is weird... --ps founder + principal interaction architect man + machine interface works http://mmiworks.net/blog : on interaction architecture ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
Hello Rahul:
i m a student and interested in gsoc project:Fast Adaptive Resampler
Tailored For Transformations Which Mostly Downsample
I have read the requirements properly for this project which also
includes jacobian transformation,box filtering algorithm and
bilinear resampling.But i am having some problem in relating all
these in one algorithm. Please guide me.Also I would like to know
the status of this project progress.
The programming for this project has not started. No progress is
consequently a fair description.
This would be a brand new way of doing downsampling, so I can't point
you to one algorithm.
Computing jacobian information (for an arbitrary point transformation)
approximately using finite differences is probably too ambitious. My
current opinion is that this method should only be used when the point
transformation communicates this information to the sampler. This
probably means that a point transformation (e.g., scale, rotate) needs
to have this info part of its implementation as an object. I'll need
opinions from people who know better at some point.
You need to understand exact area methods, and in particular, exact
area box filtering (basically, you understand images as being a
piecewise constant surface, with the pieces determined by the set of
points which are closer to a pixel center than any other pixel center,
and you (approximately) integrate this surface over an area associated
with the new pixel centers (determined by the point transformation).
References which may help understand what is going on are
@TechReport{Dodgson,
author = {N. A. Dodgson},
title ={Image resampling},
institution = {University of Cambridge Computer Lab.},
year = 1992,
number = {UCAM--CL--TR--261},
address = {15 JJ Thomson Avenue, Cambridge CB3 0FD, UK},
month ={Aug.}
}
and
@inproceedings{DBLP:conf/iciar/RobidouxTGT08,
author= {Nicolas Robidoux and
Adam Turcotte and
Minglun Gong and
Annie Tousignant},
title = {Fast Exact Area Image Upsampling with Natural Biquadratic
Histosplines},
pages = {85-96},
ee= {http://dx.doi.org/10.1007/978-3-540-69812-8_9},
bibsource = {DBLP, http://dblp.uni-trier.de},
crossref = {DBLP:conf/iciar/2008}
}
Also, a student and I programmed a C filter (for 8-bit ppm/pgm) which
does exact area box filtering in the very simple case of pure image
resizing. If you're still interested, we'll put this on the web.
The proposed method is none of the above. More precisely, it is a
composite method: It fits a new fast but accurate downsampling
method (related to box filtering) and bilinear together so that
Frankenstein is flexible and smoothly varying.
Note: French is my mother tongue. If you are more comfortable in
French, you can communicate with me---not this list---in
French. Obviously, English is fine too.
Best of luck,
Nicolas Robidoux
Universite Laurentienne
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
On Tue, Mar 10, 2009 at 1:37 PM, hOSHI wrote: Which is also usually considered as bad practice. Sorry :) considered by whom? in a professional tool there need to be some settings. In my long-time observation people who express their opinion in the lines of fine with me as long as you make it optional and get what they ask for end up with ultimately cluttered UIs. A tool should work out of box and help getting the work done right away. When people rely on customization instead, they *usually* create interfaces that require customization *before* you actually can start doing anything. Can you still recall the mess called This is the first time you run GIMP, so go make yourself a pint of coffee, sit back and go through this long and stupid wizard? This is why I say that customization is overrated. What I suggest you is to look really well at your proposal: it basically boils down to making a good deal of proposed functionality not obvious. And while having side-by-side views definitely has a place in workflow of an art-director or a collage designer, hiding correspondent prefs would be a nightmare. Alexandre ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Dockable Dialogs Should be Dockable Everywhere
Alexandre Prokoudine wrote: A tool should work out of box and help getting the work done right away. When people rely on customization instead, they *usually* create interfaces that require customization *before* you actually can start doing anything. Okay i agree on that. I really would love gimp to work as i need it to do right from the start. but as many like it to work otherwise that won't be happening soon ;) but with dialogs dockable as a default (without settings) i would not mind. (dockable in a main window i mean) ;) Alexandre Prokoudine wrote: What I suggest you is to look really well at your proposal: it basically boils down to making a good deal of proposed functionality not obvious. And while having side-by-side views definitely has a place in workflow of an art-director or a collage designer, hiding correspondent prefs would be a nightmare. okay, i see your point. so let's not use preferences but a nice icon to enable that view ;) i think i like that even better. (and just one (maybe clustered) transform-tool icon instead of the 6 now) ;) -- View this message in context: http://www.nabble.com/Dockable-Dialogs-Should-be-Dockable-Everywhere-tp21279278p22436485.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
On Mar 10, 2009, at 8:56 AM, Nicolas Robidoux wrote:
Hello Rahul:
i m a student and interested in gsoc project:Fast Adaptive Resampler
Tailored For Transformations Which Mostly Downsample
I have read the requirements properly for this project which also
includes jacobian transformation,box filtering algorithm and
bilinear resampling.But i am having some problem in relating all
these in one algorithm. Please guide me.Also I would like to know
the status of this project progress.
The programming for this project has not started. No progress is
consequently a fair description.
Computing jacobian information (for an arbitrary point transformation)
approximately using finite differences is probably too ambitious. My
current opinion is that this method should only be used when the point
transformation communicates this information to the sampler. ...
Numerical Jacobian calculation is not so bad in terms of coding effort
--
you can use the method I implemented for PDL::Transform (available as
part
of the PDL package for Perl, or at pdl.perl.org), and it's
straightforward
to code. The PDL::Transform resampling code switches its sampling
technique
based on user input; Jacobian based spatially variable filters are used
where artifact avoidance is most important. It might make a nice
starting
point for you to look at.
On the other hand, you will need to think a bit about the Fast part,
which
the PDL Jacobian-driven sampling is not -- mostly because of the need to
supply input and output filtering. I did that by padding the singular
values
of the Jacobian to approximate the effect of convolving one-pixel-wide
input
and output filter kernels with the calculated sampling kernel. That
requires
subjecting a matrix to singular value decomposition for every pixel -
there
is almost certainly a faster way to do it. For linear transformations
(where
the Jacobian is constant) the method is much faster.
Dodgson is a great reference (in Nicolas' email). You might also like
to
read Ken Turkowski's nice overview of resampling theory:
http://www.worldserver.com/turk/computergraphics/ResamplingFilters.pdf
My own paper on the subject (in the context of image resampling for
scientific
applications) is here:
http://adsabs.harvard.edu/abs/2004SoPh..2193D
You need to understand exact area methods, and in particular, exact
area box filtering (basically, you understand images as being a
piecewise constant surface, with the pieces determined by the set of
points which are closer to a pixel center than any other pixel center,
and you (approximately) integrate this surface over an area associated
with the new pixel centers (determined by the point transformation).
References which may help understand what is going on are
@TechReport{Dodgson,
author = {N. A. Dodgson},
title ={Image resampling},
institution = {University of Cambridge Computer Lab.},
year = 1992,
number = {UCAM--CL--TR--261},
address = {15 JJ Thomson Avenue, Cambridge CB3 0FD, UK},
month ={Aug.}
}
and
@inproceedings{DBLP:conf/iciar/RobidouxTGT08,
author= {Nicolas Robidoux and
Adam Turcotte and
Minglun Gong and
Annie Tousignant},
title = {Fast Exact Area Image Upsampling with Natural
Biquadratic
Histosplines},
pages = {85-96},
ee= {http://dx.doi.org/10.1007/978-3-540-69812-8_9},
bibsource = {DBLP, http://dblp.uni-trier.de},
crossref = {DBLP:conf/iciar/2008}
}
Also, a student and I programmed a C filter (for 8-bit ppm/pgm) which
does exact area box filtering in the very simple case of pure image
resizing. If you're still interested, we'll put this on the web.
The proposed method is none of the above. More precisely, it is a
composite method: It fits a new fast but accurate downsampling
method (related to box filtering) and bilinear together so that
Frankenstein is flexible and smoothly varying.
Note: French is my mother tongue. If you are more comfortable in
French, you can communicate with me---not this list---in
French. Obviously, English is fine too.
Best of luck,
Nicolas Robidoux
Universite Laurentienne
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
Hello Craig: Numerical Jacobian calculation is not so bad in terms of coding effort The issue is that, if I understand correctly, GEGL's current pure demand-driven structure means that resamplers have no information whatsoever about what other nearby locations are being resampled, and consequently there would need to be major changes to make this info available for arbitrary transformations (with, most likely, serious speed impact). Once you have it, sure, computing approximate Jacobian matrices is no big deal (provided you make sure that you stay from singularity). Hence my pragmatic choice to reserve the use of the novel (not so sure anymore that it's really new) method for tasks for which the jacobian is easy to compute and pass on. (This is the: ask people who know better part.) Does this make sense to you? Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
Hello Rahul: Indeed, the GSoC I suggested can be roughly described as implementing a poor man's version of the scheme Craig describes in http://adsabs.harvard.edu/abs/2004SoPh..2193D Replace circles/ellipses by parallelograms/rectangles, and notice that padding the singular values of the Jacobian to 1 is more or less equivalent to exact area box filtering with sides no less than the input image's inter-pixel distance, and one gets more or less the same thing. This being said, what I have in mind in way simpler than what Craig implemented. But if you understand Craig's paper, you probably understand what I want to do. Nicolas Robidoux Universite Laurentienne ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Font are small of tool-box in gimp 2.5.4
* app/widgets/gimpdock.c: made the font scale factor for the docks configurable in gtkrc. * themes/Default/gtkrc * themes/Small/gtkrc: for documentation purposes, added the default value for GimpDock::font-scale here. Changed all style property names to use the canonical names. It doesn't work (using ubuntu intrepid). Changing the GimpDock::font-scale entry has no effect whatsoever on the appearance of the fonts. Yet another pointless and annoying UI change. Please put it back the way it used to be, it wasn't a problem until you messed about with it. -- Pigeon ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
This being said, what I have in mind in way simpler than what Craig implemented. But if you understand Craig's paper, you probably understand what I want to do. Actually, if I took the time to completely understand Craig's paper, I probably would understand what I want to do. ;-) Nicolas Robidoux Laurentian University ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] GSOC Project-Fast Adaptive Resampler Tailored
Rahul: exact area box filtering with sides no less than the input image's inter-pixel distance This was a bit terse: Exact area box filtering with a square box with diameter equal to the inter-pixel distance is exactly bilinear interpolation. So, it's only when the sides are larger than the scheme is not bilinear. nicolas ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Font are small of tool-box in gimp 2.5.4
Pigeon wrote:
* app/widgets/gimpdock.c: made the font scale factor for the docks
configurable in gtkrc.
* themes/Default/gtkrc
* themes/Small/gtkrc: for documentation purposes, added the
default value for GimpDock::font-scale here. Changed all style
property names to use the canonical names.
It doesn't work (using ubuntu intrepid).
Changing the GimpDock::font-scale entry has no effect whatsoever on the
appearance of the fonts.
Yet another pointless and annoying UI change. Please put it back the way it
used to be, it wasn't a problem until you messed about with it.
Works for me when I put this:
style gimp-default-style
{
GimpDock::font-scale = 2.8333
}
in ~/.gimp-2.7/gtkrc. Are you sure you had the right syntax in your gtkrc?
- Martin
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Font are small of tool-box in gimp 2.5.4
Hi, On Tue, 2009-03-10 at 21:20 +0100, Pigeon wrote: * app/widgets/gimpdock.c: made the font scale factor for the docks configurable in gtkrc. * themes/Default/gtkrc * themes/Small/gtkrc: for documentation purposes, added the default value for GimpDock::font-scale here. Changed all style property names to use the canonical names. It doesn't work (using ubuntu intrepid). It works just fine for me and for everyone else. Changing the GimpDock::font-scale entry has no effect whatsoever on the appearance of the fonts. Yet another pointless and annoying UI change. Please put it back the way it used to be, it wasn't a problem until you messed about with it. If your mail wasn't so rude, I might even try to find out why it doesn't work for you. But why should I even talk to you? You have managed to look up the change in the ChangeLog, you can revert it in your copy of the source code if that makes you feel better. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] How to find someone to modify GIMP for me?
Hi everyone, a passing civilian hereI want a modified version of GIMP, but don't know anything about programming and so will not be doing the work myself! Is there a place I can go to find developers/programmers for hire to do the work? -- View this message in context: http://www.nabble.com/How-to-find-someone-to-modify-GIMP-for-me--tp22446438p22446438.html Sent from the Gimp Developer mailing list archive at Nabble.com. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
