Re: [Gimp-developer] couple possible TODO items
At 11:43 PM 03/28/2001 +0200, you wrote: >On 27 Mar, Zachary Beane wrote: > > Are credit cards of a standard size? > > Should be. I wouldn't trust sticking them into a machine otherwise. Using a credit card as a standard object for calibration is not a good idea. Students in high school (for e.g.) that want to use the GIMP are very unlikely to have credit cards. Cheers! Kevin. (http://www.interlog.com/~kcozens/) E-mail:kcozens at interlog dot com|"What are we going to do today, Borg?" or:ve3syb at rac dot ca |"Same thing we always do, Pinkutus: Packet:ve3syb@ve3yra.#con.on.ca.na| Try to assimilate the world!" #include| -Pinkutus & the Borg ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
Zachary Beane wrote: > Well, A4 was hypothetical. Perhaps it could have a number of standard > objects (A4 paper, US Letter paper, CD) that you could choose from to > do your sizing. > > Are credit cards of a standard size? > What about those little end pieces of 35mm film that have no pictures? Even the sprocket holes should be standard. Or photos. Machines do so much of the processing now, perhaps they are standard by now. It seems like 4x6 would be a good size for many resolutions of screen. Letter size seems too big for my 800x640 display. Credit cards could be scratchy also. Besides, credit card companies are evil. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
On 29 Mar 2001, Sven Neumann wrote: > > > Are credit cards of a standard size? > > > > Should be. I wouldn't trust sticking them into a machine otherwise. > > They should be, but IMO credit cards are too small to be used > for resolution calibration. I guess it's the physician in me but > I think we should use something that is at least half the size > of the screen to reduce the error. > > > I suggest we talk to the Gimp-Print people and come up with a > nice paper-selection framework offering all sorts of paper sizes > in use all over the world and use that in the image->new dialog, > for printing and for the calibration dialog. Ugh, speaking of error, all so-called "letter" paper isn't necessarily the same size. I've had two "letter" papers vary in size by almost half a centimeter! Rockwlrs ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
Hi, On Wed, Mar 28, 2001 at 01:12:28PM +0200, Sven Neumann wrote: > > > - Biased color reduction > > > > > > This is a feature I saw in photoshop. When reducing the colors of an > > > image, it will try to preserve colors within the active selection > > > more than it tries to preserve those outside of it. For example, if > > > you want to keep skin tones in an image, but want to otherwise > > > reduce the overall number of colors, you would select a few > > > representative areas of skin before doing the reduction. > > > Personally, I can't count the number of times I've converted an image > > to Indexed only to find the black had gone suddenly slightly > > off-black, or another solid color that I really needed at a particular > > value had suddenly shifted slightly. I'd love to be able to select > > those colors before conversion to hint to the Indexed conversion, > > "these exact values are important to me." > > Talked to Adam about that issue on #gimp lately and he seems to be > biased towards changing the conversion-algorithm to be intelligent > enough to do the right thing without user interaction. I doubt that this is possible. An algorithm simply cannot guess that those three black pixels are more important to me than those two thousand gray ones. We need to be able to flag some colors sticky - e.g. for logo / Corporate Identity work where colors are fixed and must not be changed. It would have another advantage, especially for web work: I could fix the important colors and reduce further (to reduce file size) while this might not be possible if the algorithm chooses all colors itself. Though, I don't have an idea of how the GUI allowing sticky colors could look like. :-( Just my two (Euro)cents, Tino. -- * LINUX - Where do you want to be tomorrow? * http://www.tu-chemnitz.de/linux/tag/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
Hi, Zachary Beane <[EMAIL PROTECTED]> writes: > > - Biased color reduction > > > > This is a feature I saw in photoshop. When reducing the colors of an > > image, it will try to preserve colors within the active selection > > more than it tries to preserve those outside of it. For example, if > > you want to keep skin tones in an image, but want to otherwise > > reduce the overall number of colors, you would select a few > > representative areas of skin before doing the reduction. > Personally, I can't count the number of times I've converted an image > to Indexed only to find the black had gone suddenly slightly > off-black, or another solid color that I really needed at a particular > value had suddenly shifted slightly. I'd love to be able to select > those colors before conversion to hint to the Indexed conversion, > "these exact values are important to me." Talked to Adam about that issue on #gimp lately and he seems to be biased towards changing the conversion-algorithm to be intelligent enough to do the right thing without user interaction. According to the latest ChangeLog entries, he seems to be actually working on this. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
Hi, [EMAIL PROTECTED] writes: > > Are credit cards of a standard size? > > Should be. I wouldn't trust sticking them into a machine otherwise. They should be, but IMO credit cards are too small to be used for resolution calibration. I guess it's the physician in me but I think we should use something that is at least half the size of the screen to reduce the error. I suggest we talk to the Gimp-Print people and come up with a nice paper-selection framework offering all sorts of paper sizes in use all over the world and use that in the image->new dialog, for printing and for the calibration dialog. Salut, Sven ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
On 27 Mar, Zachary Beane wrote: > Are credit cards of a standard size? Should be. I wouldn't trust sticking them into a machine otherwise. -- Servus, Daniel ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
Zachary Beane wrote: > > > > This is a feature I saw in photoshop. When reducing the colors of an > > > > image, it will try to preserve colors within the active selection > > > > more than it tries to preserve those outside of it. This is one issue... > > > I'd love to be able to select > > > those colors before conversion to hint to the Indexed conversion, > > > "these exact values are important to me." And this is a different one. Now you've made me break out my email client six months ahead of schedule... you'll be sorry. [sven n.] > > Talked to Adam about that issue on #gimp lately and he seems to be > > biased towards changing the conversion-algorithm to be intelligent > > enough to do the right thing without user interaction. According > > to the latest ChangeLog entries, he seems to be actually working on > > this. > > how can the conversion algorithm know what the right thing > is? If I'm going from many colors (one of which is a particular shade > of mauve that matches my web page) to, say, 11 colors, how can it know > that my mauve is one of the colors to preserve unmodified? It can't, and that's why it's a different issue. I assume that Sven was responding to the former of your requests; I did not discuss the latter. I am not enamored with the idea of manually hinting at areas of image to be biased in the colour histogram. There are a number of reasons for this. The foremost is that it's simply a cop-out. The only reason that someone would want to do this would be if they thought that GIMP wasn't doing a good job *without* hinting. I'd rather address the root cause there; there's still lots of room for improvement without resorting to a crutch that naive users might cheerfully wield to their own detriment. Abusing the metaphor, we'll fit the crutch when the leg is mangled beyond healing. As to the other point, I've always actually been dead keen on the idea of 'fixing' colours that the user wants inviolate; the algorithm can't guess the user's own nefarious reasons for wanting a particular colour fixed in this way. This is actually somewhat harder to do the *right* way than the former biasing issue, but it's quite doable. I'll hopefully get around to it one of these years. (It requires algorithm plumbing to do right, though, if someone else wants to try -- no 'quantize to N-M colours and then slot in our M fixed colours afterwards' hacks.) FYI my local tree already has the changes in for quantization, mapping and dithering in CIE L*a*b* colourspace (assuming sRGB source since we don't have any sort of colour management), but also bugs, octopi and other creeping horrors. --Adam -- Adam D. Moss. ,,^^[EMAIL PROTECTED]http://www.foxbox.org/ co:3 i l1x0r u! 5luRp! ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
On Wed, Mar 28, 2001 at 01:12:28PM +0200, Sven Neumann wrote: > Hi, > > Zachary Beane <[EMAIL PROTECTED]> writes: > > > > - Biased color reduction > > > > > > This is a feature I saw in photoshop. When reducing the colors of an > > > image, it will try to preserve colors within the active selection > > > more than it tries to preserve those outside of it. For example, if > > > you want to keep skin tones in an image, but want to otherwise > > > reduce the overall number of colors, you would select a few > > > representative areas of skin before doing the reduction. > > > Personally, I can't count the number of times I've converted an image > > to Indexed only to find the black had gone suddenly slightly > > off-black, or another solid color that I really needed at a particular > > value had suddenly shifted slightly. I'd love to be able to select > > those colors before conversion to hint to the Indexed conversion, > > "these exact values are important to me." > > Talked to Adam about that issue on #gimp lately and he seems to be > biased towards changing the conversion-algorithm to be intelligent > enough to do the right thing without user interaction. According > to the latest ChangeLog entries, he seems to be actually working on > this. His ChangeLog entries are what renewed my interest in this. But I'm curious; how can the conversion algorithm know what the right thing is? If I'm going from many colors (one of which is a particular shade of mauve that matches my web page) to, say, 11 colors, how can it know that my mauve is one of the colors to preserve unmodified? Zach -- [EMAIL PROTECTED] Zachary Beane http://www.xach.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
On Tue, Mar 27, 2001 at 11:34:24PM +0100, Nick Lamb wrote: > On Tue, Mar 27, 2001 at 05:00:49PM -0500, Zachary Beane wrote: > > now. Rather than the current system of "measure this item onscreen > > and enter the figure from your ruler" to calculate DPI, I think it > > would be more userfriendly to have the shape of some common object > > that you could stretch to fit. For example, you could select A4 > > paper, place the top of a sheet against the monitor, and stretch or > > shrink the virtual outline until it fits the physical outline. That > > would give a pretty decent measurement, I think > > IMHO (I have thought about this before) the perfect object is a CD > There is nowhere in the world which does not have CDs, they are always > the same size to within mm and they are perfectly round, so they can > easily be used to check that your circles are circular _if_ that is > what you want (cheap screens will distort things too badly for this to > be worth attempting). I'm concerned about a CD because I have an anti-glare coating that almost certainly would be marred by pressing a CD against it. It is one of the few universal standards we could come up with on our #gimp brainstorm though (double-a batteries being another :). > I'm too busy to do anything about it though, so if a piece of A4 paper > floats your goat, go for it! It's about time the Americans finally > caught up to the 20th century and went metric anyway... Well, A4 was hypothetical. Perhaps it could have a number of standard objects (A4 paper, US Letter paper, CD) that you could choose from to do your sizing. Are credit cards of a standard size? Zach -- [EMAIL PROTECTED] Zachary Beane http://www.xach.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
On Tue, Mar 27, 2001 at 05:00:49PM -0500, Zachary Beane wrote: > now. Rather than the current system of "measure this item onscreen > and enter the figure from your ruler" to calculate DPI, I think it > would be more userfriendly to have the shape of some common object > that you could stretch to fit. For example, you could select A4 > paper, place the top of a sheet against the monitor, and stretch or > shrink the virtual outline until it fits the physical outline. That > would give a pretty decent measurement, I think IMHO (I have thought about this before) the perfect object is a CD There is nowhere in the world which does not have CDs, they are always the same size to within mm and they are perfectly round, so they can easily be used to check that your circles are circular _if_ that is what you want (cheap screens will distort things too badly for this to be worth attempting). I'm too busy to do anything about it though, so if a piece of A4 paper floats your goat, go for it! It's about time the Americans finally caught up to the 20th century and went metric anyway... Nick. ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
Re: [Gimp-developer] couple possible TODO items
On Tue, Mar 27, 2001 at 05:00:49PM -0500, Zachary Beane wrote: > I have a couple things in my wishlist that I'd like to add to > TODO.xml. > > - Biased color reduction > > This is a feature I saw in photoshop. When reducing the colors of an > image, it will try to preserve colors within the active selection > more than it tries to preserve those outside of it. For example, if > you want to keep skin tones in an image, but want to otherwise > reduce the overall number of colors, you would select a few > representative areas of skin before doing the reduction. To reply to myself on this... Personally, I can't count the number of times I've converted an image to Indexed only to find the black had gone suddenly slightly off-black, or another solid color that I really needed at a particular value had suddenly shifted slightly. I'd love to be able to select those colors before conversion to hint to the Indexed conversion, "these exact values are important to me." Zach -- [EMAIL PROTECTED] Zachary Beane http://www.xach.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
[Gimp-developer] couple possible TODO items
I have a couple things in my wishlist that I'd like to add to TODO.xml. - Biased color reduction This is a feature I saw in photoshop. When reducing the colors of an image, it will try to preserve colors within the active selection more than it tries to preserve those outside of it. For example, if you want to keep skin tones in an image, but want to otherwise reduce the overall number of colors, you would select a few representative areas of skin before doing the reduction. - Monitor resolution calculation This idea has been kicking around in my head for quite some time now. Rather than the current system of "measure this item onscreen and enter the figure from your ruler" to calculate DPI, I think it would be more userfriendly to have the shape of some common object that you could stretch to fit. For example, you could select A4 paper, place the top of a sheet against the monitor, and stretch or shrink the virtual outline until it fits the physical outline. That would give a pretty decent measurement, I think (This program could also be completely standalone, as I think it would be useful at other times than GIMP installation.) What do you think? Zach -- [EMAIL PROTECTED] Zachary Beane http://www.xach.com/ ___ Gimp-developer mailing list [EMAIL PROTECTED] http://lists.xcf.berkeley.edu/mailman/listinfo/gimp-developer
