Re: [Gimp-developer] Scale bars in 2.7
Hi, I think this is already being adressed for 2.8. You are not the only one who is bothered by this. Basing the rate of change upon the current zoom is a very good idea! It would definitly make sense to have the slider automatically cover a range between 1px and half-the-smallest-width-of-visible-canvas On Mon, Jan 24, 2011 at 12:33:36AM +0100, Emil Assarsson wrote: Hi all, I know that 2.7 is still in development and much will change but I hope you don't mind some comments. This is about the scale bars in the brush attribute editor etc. I find it hard to use especially when I try to set the Size to something less than 40 in the normal width. Is it possible to add some kind of decelerator (hotkey?) on those so it would be easier to fine tune? I find the small up and down buttons useless. It might be an idea to adjust the scale to reflect the zoom from 1:1 pixel? It would also be nice if the number where selected so they easily could be replaced with a new value without having to try to select it by dragging the mouse pointer which may or may not work depending on where the scale bar is located. BR Emil Assarsson ___ 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
[Gimp-developer] Scale bars in 2.7
Hi all, I know that 2.7 is still in development and much will change but I hope you don't mind some comments. This is about the scale bars in the brush attribute editor etc. I find it hard to use especially when I try to set the Size to something less than 40 in the normal width. Is it possible to add some kind of decelerator (hotkey?) on those so it would be easier to fine tune? I find the small up and down buttons useless. It might be an idea to adjust the scale to reflect the zoom from 1:1 pixel? It would also be nice if the number where selected so they easily could be replaced with a new value without having to try to select it by dragging the mouse pointer which may or may not work depending on where the scale bar is located. BR Emil Assarsson ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scale
On Sunday, October 03, 2010 04:10:08 Melissa Young wrote: Hi, I am creating a new image that is 1265 x 1610 pixels. I am making a photo collage with 9 different pictures. Earlier today I was able to scale the image to 3.66 (width) x 4.66 (height) pixels. I am not able to do that anymore. When I try to put a decimal point the program doesn't even recognize the decimal. How can I fix this where I am able to do decimals in the pixel setting when scaling a picture? Melissa Pixel values can only be integers. Nothing to do with gimp, just with what a pixel is. Pixel is the smallest unit of information the image contains. You cant split it any smaller. You probably scaled in some different unitspace before. Open one of those images and see how big it really is in pixels. Also, why on earth do you want to scale with that sort of (impossible) accuracy? -- Alexia ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] Scale
Hi, I am creating a new image that is 1265 x 1610 pixels. I am making a photo collage with 9 different pictures. Earlier today I was able to scale the image to 3.66 (width) x 4.66 (height) pixels. I am not able to do that anymore. When I try to put a decimal point the program doesn't even recognize the decimal. How can I fix this where I am able to do decimals in the pixel setting when scaling a picture? Melissa ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] Scale
On 10/02/10 21:10, Melissa Young wrote: Hi, I am creating a new image that is 1265 x 1610 pixels. I am making a photo collage with 9 different pictures. Earlier today I was able to scale the image to 3.66 (width) x 4.66 (height) pixels. 3.66 x 4.66 pixels makes no sense--that's about the size of text comma. I suspect you were scaling to inches, millimetres, points, or some other unit. Look to the right of the numeric boxes on the scale dialogue--that's where the units are set. I am not able to do that anymore. When I try to put a decimal point the program doesn't even recognize the decimal. How can I fix this where I am able to do decimals in the pixel setting when scaling a picture? Melissa ___ 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] scale-region.c
On Mon, 2008-08-25 at 09:46 +0200, Sven Neumann wrote: [...] This is just a bug in the progress code in scale-region.c. I am on it, should be fixed by tonight. Oh you sexy bean! Now that you ahve indeed stopped gimp from hanging... timings for the 13818x8480 image are scaling down to 50%: 6 seconds (was 30 seconds a few days ago) scaling down to 51%: 6 seconds (was 41 seconds a few days ago) Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scale-region.c
Hi, On Sun, 2008-08-24 at 15:27 -0400, Liam R E Quin wrote: By freeze-at-end I mean that the progress bar stops moving when it is almost at the very end; my guess is that it's pushing onto the undo stack and also maybe generating a thumbnail for the undo history, but that's an uninformed guess :-) This is just a bug in the progress code in scale-region.c. I am on it, should be fixed by tonight. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scale-region.c
Sven Neumann wrote: Hi Geert, I have a small patch to scale-region.c that I would to have your opinion on. I noticed that the current code sometimes does an unneeded copy operation. This happens when the scale factor is 2^n. For example when an image of 800x600 pixels is scaled to 400x300. The function determine_scale() then decides that a first scale step to 400x300 needs to be made and the result is then scaled again with a scale factor of 1.0. There's even an optimization n the scale() function for this special case. Attached is a patch that changes determine_scale() to avoid this extra step. Is there anything that I am missing or do you agree that it should be safe to apply this? Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer I see no problem with that,it should be safe. ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scale-region.c
Hi, On Sun, 2008-08-24 at 14:59 +0200, Geert Jordaens wrote: I see no problem with that,it should be safe. Thanks for the review. I have committed this change and some other cleanups and optimizations to SVN trunk last night. This gives a small but noticeable speedup. I hope that my changes did not introduce any new bugs, but I am quite confident that I haven't broken anything. Sven ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scale-region.c
On Sun, 2008-08-24 at 19:09 +0200, Sven Neumann wrote: [...] Thanks for the review. I have committed this change and some other cleanups and optimizations to SVN trunk last night. This gives a small but noticeable speedup. I hope that my changes did not introduce any new bugs, but I am quite confident that I haven't broken anything. Some informal (approximate) timings with a grayscale image, 13818x8480 pixels (a sketch by Sydney Jones). before patch: scale 50% = 18 seconds to freeze-at-end, 31 secs overall 17 seconds to freeze-at-end, 29 secs overall 51% = 14 seconds to freeze-at-end, 43 secs overall 11 seconds to freeze-at-end, 40 secs overall after patch: scale 50% = 07 seconds to freeze-at-end, 24 secs overall 07 seconds to freeze-at-end, 25 secs overall 51% = 09 seconds to freeze-at-end, 34 secs overall 10 seconds to freeze-at-end, 35 secs overall I did the timings more than once. I have 8G of RAM and a 7G tile cache size (on Sven's suggestion - it does seem to speed things up) By freeze-at-end I mean that the progress bar stops moving when it is almost at the very end; my guess is that it's pushing onto the undo stack and also maybe generating a thumbnail for the undo history, but that's an uninformed guess :-) The speedup for the first part is very noticeable, e.g. 18 secs - 7 secs, but it makes the frozen part more noticeable, and as a result actually seems slower. I did not do regression testing, comparing the results, sorry. Liam -- Liam Quin - XML Activity Lead, W3C, http://www.w3.org/People/Quin/ Pictures from old books: http://fromoldbooks.org/ Ankh: irc.sorcery.net irc.gnome.org www.advogato.org ___ Gimp-developer mailing list Gimp-developer@lists.XCF.Berkeley.EDU https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
[Gimp-developer] scale-region.c
Hi Geert,
I have a small patch to scale-region.c that I would to have your opinion
on. I noticed that the current code sometimes does an unneeded copy
operation. This happens when the scale factor is 2^n. For example when
an image of 800x600 pixels is scaled to 400x300. The function
determine_scale() then decides that a first scale step to 400x300 needs
to be made and the result is then scaled again with a scale factor of
1.0. There's even an optimization n the scale() function for this
special case.
Attached is a patch that changes determine_scale() to avoid this extra
step. Is there anything that I am missing or do you agree that it should
be safe to apply this?
Sven
Index: app/paint-funcs/scale-region.c
===
--- app/paint-funcs/scale-region.c (revision 26730)
+++ app/paint-funcs/scale-region.c (working copy)
@@ -170,7 +170,7 @@ determine_scale (PixelRegion *srcPR,
*max_progress = ((height % TILE_HEIGHT) + 1) * ((width % TILE_WIDTH) + 1);
/* determine scaling levels */
- while (scalex = 2)
+ while (scalex 2)
{
scalex /= 2;
width *=2;
@@ -179,7 +179,7 @@ determine_scale (PixelRegion *srcPR,
((width % TILE_WIDTH) + 1));
}
- while (scaley = 2)
+ while (scaley 2)
{
scaley /= 2;
height *= 2;
@@ -188,7 +188,7 @@ determine_scale (PixelRegion *srcPR,
((width % TILE_WIDTH) + 1));
}
- while (scalex = 0.5)
+ while (scalex 0.5)
{
scalex *= 2;
width /= 2;
@@ -197,7 +197,7 @@ determine_scale (PixelRegion *srcPR,
((width % TILE_WIDTH) + 1));
}
- while (scaley = 0.5)
+ while (scaley 0.5)
{
scaley *= 2;
height *= 2;
@@ -370,6 +370,9 @@ scale_region_tile (PixelRegion
/* determine scaling levels */
determine_scale (srcPR, dstPR, levelx, levely, max_progress);
+ g_printerr (%d x %d - %d x %d: %d, %d\n,
+ width, height, dstPR-w, dstPR-h, levelx, levely);
+
if (levelx == 0 levely == 0)
{
scale (srcTM, dstTM, interpolation,
___
Gimp-developer mailing list
Gimp-developer@lists.XCF.Berkeley.EDU
https://lists.XCF.Berkeley.EDU/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scale image/layer UI analysis
Hi, Jakub Steiner [EMAIL PROTECTED] writes: I have planned to come up with a better interface for the scale dialogs. The task turned out to be more complex than I initially thought. Because I will probably be busy until next weekend I am posting the unfinished work here for some discussion that could help push things forward. Only the image scale dialog has been mocked up in glade for now, although suggestions how to solve the defined tasks are suggested. No UI for that yet. There are couple of open issues even with the scale image dialog. * The header could stay, showing not only a thumbnail, filename, but perhaps also the original pixel size (see below). If you are talking about the dialog header provided by GimpViewableDialog, can we please consider keeping it? We are using this dialog all over the place and IMO it is very useful that the header shows - the icon that is also used in the menus - a descriptive title of the action associated with this dialog - a preview and the name of the viewable (image/drawable) that this dialog operates on IMHO removing this header would be a regression. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scale image/layer UI analysis
Hi, On Mon, 2004-05-17 at 10:59, Sven Neumann wrote: If you are talking about the dialog header provided by GimpViewableDialog, can we please consider keeping it? We are using this dialog all over the place and IMO it is very useful that the header shows - the icon that is also used in the menus - a descriptive title of the action associated with this dialog - a preview and the name of the viewable (image/drawable) that this dialog operates on IMHO removing this header would be a regression. I agree. We're working hard to make all our dialogs have a consistent look and feel - GimpViewableDialog does a great job in simplifying this task. Regards, Brix -- Henrik Brix Andersen [EMAIL PROTECTED] ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scale image/layer UI analysis
On 17 May 2004, Sven Neumann wrote: Well, we don't have such an entry and I don't see it being added for GIMP 2.2. So for now we should IMO keep the changes to the dialog purely cosmetic. It will help users to be able to recognize the Scale dialog that they have worked with in earlier GIMP versions. Also it makes the code changes easier to do in the limited timeframe that is left before 2.2 is supposed to be done. * The ratio control has been dropped, since it effectively duplicates the % unit. I'd rather drop the % unit since I don't think that it is intuitive enough. From my experience the ratio control is the most used control in this dialog and IMO it should stay. I agree. Percentage changes are definately common enough to warrant their own control set. Percentage isn't even considered a unit outside of the computer graphics world, so most people wouldn't think of using a units selector to select a percentage. Now, if the default on this dialog was always %, that might work, but it might cause other problems as well. Something to test in the lab. Rockwalrus ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] scale image/layer UI analysis
On Mon, May 17, 2004 at 06:26:16AM +0200, Jakub Steiner wrote: * The ratio control has been dropped, since it effectively duplicates the % unit. I think there should be fields for the aspect ratio (not starting on 1x1 but actual values). * Print resolution has been removed (discussed at task 6 below) For me, changing print resolution is an integral part of scaling. Say you have a scanned image and need to scale it down for a layout. Print resolution would go up without intervention. Being able to restrict it to the highest value that makes sense in one go would be a good thing. The problem I have with the current dialog, or that of PS, is that it's hard to understand what will change, when you enter a value somewhere. I think a solution might be to split things up into 3 areas: - Current values (just output, not editable) - Target values. Start with empty fields. The user can add target values until everything can be determined (left input fields will be disabled). Because all possible tasks are realy about defining target values, and having feedback about what else will change and how (see next one). - Final values (not editable). The consequences of initilal values and target values. The values are: - pixel or % width and height - print width and height - resolution - aspect ratio (important for artistic work, giving a work a nice shape) Oh, and finaly Quality/Interpolation should be in the dialog, because it's something to decide on per image. --- Thorsten Wilms ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] scale image/layer UI analysis
Hi folks. I have planned to come up with a better interface for the scale dialogs. The task turned out to be more complex than I initially thought. Because I will probably be busy until next weekend I am posting the unfinished work here for some discussion that could help push things forward. Only the image scale dialog has been mocked up in glade for now, although suggestions how to solve the defined tasks are suggested. No UI for that yet. There are couple of open issues even with the scale image dialog. * The header could stay, showing not only a thumbnail, filename, but perhaps also the original pixel size (see below). * Task No.7 is calling for some sort of preview control within the dialog (perhaps embedded in the disclosure triangle) control similar to what we have for changing canvas size, except with pixmap preview. * Don't have a use case for why would the original pixel size be useful. Dropped it, but have a weird feeling I'm missing something. PNG mockup: http://jimmac.musichall.cz/stuff/scale-image-mockup.png glade files: http://primates.ximian.com/~jimmac/product-design/GIMP/ cheers -- Jakub Steiner [EMAIL PROTECTED] revision 0.1 - initial draft (16.5.2004) Scale Dialogs Proposal -- Background -- Pete is a webdesigner with a passion for music and photography. He runs GIMP on Linux. Tasks - 1) Pete wants to scale his photograph so that it best-fits on a CD cover to modify it later on and add a subtitle. Pete wants to keep the aspect ratio, but prefers cropping to framing. The photo he wants to put on the background of the CD cover has a 13:9 ratio. 2) Pete has a base of his CD cover done, but now needs to put a photograph below his CD title. a) The source photo is very wide and has two tall trees on the sides, but people standing next to them. He would like the trees to align with the start and end letters of the title and still make the people fit. Pete wants to keep the aspect ratio of the original photo. b) The source photo needs to fit the width of the text and height of the remaining area below the photo. c) Pete doesn't like the final size of the title/photo cobinations and wants to scale them down a little keeping them cenetered horizontally. 3) Pete has a nice 16x16 B/W icon that look very nice next to the copyright information, however it needs to be scaled up to be visible. He doesn't want it to end up all blury thanks to filtering. 4) Pete has a a set of photographs and wants them all scaled down to VGA resolution. 5) Pete needs to do an abstract wallpaper for a specific screen that he know is 2000px wide and has a 16:9 aspect ratio. He has a nice abstract 13:9 photo that can take some distortion. 6) Pete wants to see if the cover would work for the small-sized CD too. Without changing the pixel resolution, he wants to boost the print resolution. 7) Pete's friend Tom brought an screengrab from his PAL video footage that he recorded in wideangle mode and is a bit compressed horizontally. He wants to put that shot on the webpage so he'd like to correct the aspect ratio. Interface Proposal -- General --- One thing that would be very helpful everywhere in GIMP would be using a custom intelligent unit text entry. Instead of using a spinbox and a dropdown for entering numbere values and units, there could be a single entrybox accepting a number AND the unit, that would also include a simple calculator. Task 5 illustrates how it could be useful in practice. Image Scale Dialog -- Some comments * The ratio control has been dropped, since it effectively duplicates the % unit. * Print resolution has been removed (discussed at task 6 below) * Quality frame can possibly be dropped and template moved outsize the size frame as you have done with the New dialog implementation in 2.1. That goes against the suggestion of the HIG not to mix framed and unframed elements though. * Pixel size label would only appear when using non pixel units Task Accomplishment --- 1) Pete opens the new image and brings up the imagescale dialog. He slects CD as a template. The Width and Height values get unlinked. Pete changes the unit to %. He sees something like 56% for Width and 80% for Height. Because he wants the image to retain its aspect ratio, he locks W and H, focuses the H control and presses enter. That will make the Width control update to 80%. He applies the settings and brings up the ImageCanvas size dialog. Selects the CD template and presses the center button. 2a) Pete drags the source photo onto the CD cover image. With the photo layer active, he selects the scale tool which now has a live preview of the transformation (*yay* ;). /* not sure about this (would be consistant with the selection tools): Alt dragging moves the layer/selection, Shift keeps the aspect ratio, Ctrl scales centered
Re: [Gimp-developer] Scale Constrained
Hi, Jonathan Bartlett [EMAIL PROTECTED] writes: I wrote a small but useful script that will scale an image to best fit within a constrained size without affecting aspect ratio. I might miss something obvious, but I think this can be easily achieved using the existing Scale Image GUI. Also on that page is a templated images script, which is really, REALLY basic at the moment, but basically allows you to easily create image-based templates (think Print Shop). Please note that the term Template is already taken in GIMP-1.3. Templates are available in the File-New dialog and can be just an image size or even point to a template XCF to load. Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] Scale Constrained
I wrote a small but useful script that will scale an image to best fit within a constrained size without affecting aspect ratio. It's a simple script, but I've found it quite useful as a component for other scripts, and thought it might be useful in GIMP at large. It's scheme right now, but I could code it in C if you would like: http://www.eskimo.com/~johnnyb/computers/multimedia/ Also on that page is a templated images script, which is really, REALLY basic at the moment, but basically allows you to easily create image-based templates (think Print Shop). Anyway, eventually I'm going to make this into something which has the ability to intelligently search for pictures to plug in, a better UI, and a UI for creating templates. However, if someone else was interested it might go a bit faster :) I thought this would be useful enough that some of the developer community might want to be involved, so I posted here. Anyway, let me know. Jon ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
