history of "great" bugs
This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.
This is a read-only list on gimpusers.com so this discussion thread is read-only, too.
history of "great" bugs | Dima Ursu | 03 Sep 15:52 |
history of "great" bugs | Bill Skaggs | 03 Sep 16:35 |
history of "great" bugs | Liam R E Quin | 04 Sep 07:53 |
history of "great" bugs | Saul Goode | 05 Sep 18:37 |
history of "great" bugs | Alexia Death | 06 Sep 18:46 |
history of "great" bugs | yahvuu | 08 Sep 18:27 |
history of "great" bugs
Hello,
At university, at the lecture about software testing, we have been asked to look to software bugs, especially of big, known project which have caused troubles, like crashings, or some other abnormal behavior.
Does anyone remember some "great" bugs which GIMP had?
history of "great" bugs
There are hundreds of bugs that meet those criteria. Gimp maintains a bug database at bugzilla.gnome.org. Here is a search that gives you a list of major bugs that have been fixed:
You can click on any of them to see the initial bug report and the history of efforts to fix it.
- Bill
history of "great" bugs
On Mon, 2012-09-03 at 18:52 +0300, Dima Ursu wrote:
Hello,
At university, at the lecture about software testing, we have been asked to look to software bugs, especially of big, known project which have caused troubles, like crashings, or some other abnormal behavior.
Does anyone remember some "great" bugs which GIMP had?
I don't know about "great" bugs - people asking that usually like war stories rather than just searching the database.
So here's a short non-GIMP one...
I used to have some programmers working for me; we got one programmer on loan from another department. He was a good programmer by and large, but he still used the "ed" line editor rather than a "new-fangled and bloated" screen editor. He scoffed at my C coding style guidelines and said they were for dummies (e.g. requiring braces for if/else everywhere, and clear variable and function names).
Once after spending a couple of days debugging he rather shamefacedly came to me and admitted that if he'd followed the guidelines he'd have saved two days of debugging (at the expense of typing hundreds of extra brace characters, you work out which is the better deal...).
He'd added an "else" branch to an "if", not noticing that it was itself in a nested if/else, also with no braces, and the "else" had gone to the wrong "if". He didn't see it because his editor happened not to show him that line, and he wasn't using braces or indenting, to "save time".
We also had the bug where the printer "didn't work on the third wednesday of the month" but that's getting a little far afield.
If you want famous expensive bugs, the NASA project has lots, and the old Usenet comp.risks archives have lots more.
Liam
history of "great" bugs
One of the more interesting GIMP bugs is bug #162395, "Soft Light and Overlay modes are identical". This bug involves layer "blend modes" whereby the upper of two layers serves as an adjustment mask to the lower layer.
As background, it will be helpful to understand a couple of other blend modes to understand what is happening.
First is the "multiply" mode whereby the upper layer's value is multiplied by lower layer. These values are normalized such that black is "0" and white is "1"; therefore the multiplication will never produce a result any brighter than the lower layer. At best the result will be the same (when the upper layer is white), while typically the result is darker (for all other shades of the upper layer).
Next there is the "screen" mode, which is basically the converse of the "multiply" mode. The lower layer is brightened by the amount of brightness in the upper layer. The result will never be darker than original lower layer; at best the result will be the same (when the upper layer is black), while the result is typically brighter.
This brings us to the "overlay" mode, which most graphics programs define as using the "screen" mode when the upper layer is bright (above middle value) and "multiply" mode when it is dark. This has the effect of the result having much darker darks and much brighter brights. Notably, GIMP does not implement "overlay" mode in this manner.
This "overlay" mode tends to be very mathematical and often produces harsh results that are not aesthetically pleasing in the general photographic sense. There is also a discontinuity when the upper layer transitions from below middle to above middle which can produce an unnatural appearance. Because of this, graphics programs offer the "soft light" which attempts to lessen the harshness/contrast of "overlay" mode and smooth out the discontinuity at the midpoint.
How "soft light" mode works varies from program to program. My understanding is that GIMP implementation of "soft light" mode is similar to Borland's graphics library in their Delphi programming environment. This implementation is similar, but not identical, to Photoshop's "soft light" mode.
As stated earlier, GIMP does not implement "overlay" mode in the same way as other graphics programs. This is not in itself much of a problem, as there was never a standardized definition for it. Perhaps the early GIMP developers where attempting to make the "overlay" mode more useful and pleasing (just as was done for the "soft light" mode).
Nonetheless, somewhere along the line a mistake was made and GIMP's implementation of "overlay" actually ends up producing identical results to its "soft light" mode. Since the source code itself wasn't identical, this redundant behavior was not noticed until years later.
So why hasn't this bug been fixed? Quite simply there were too many plug-ins, too many users, and too many existing GIMP image files that relied upon the legacy behavior. Changing it was deemed too costly. Perhaps also considered was how the traditional "overlay" mode is not typically as useful for modifying "natural images".
While I wouldn't characterize #162395 as a "great" bug, it is a long-standing one (that is not likely to be fixed in the near future) with a storied past.
history of "great" bugs
hi,
If you want a fun bug, Id say the drag-and-drop ghost in 2.4 series(I think it got fixed by 2.6?) takes the cake. It eluded people for a while... I think it was Michael Mure before his first GSoC who found the issue...
Best,
Alexia
history of "great" bugs
Hello Saul,
Am 05.09.2012 20:37, schrieb Saul Goode:
This brings us to the "overlay" mode, which most graphics programs define as using the "screen" mode when the upper layer is bright (above middle value) and "multiply" mode when it is dark.
just a nit to pick: it is the bottom layer which determines whether to perform screening or multiplying
[..] My understanding is that GIMP implementation of "soft light" mode is similar to Borland's graphics library in their Delphi programming environment.
i presume you are referring to "Pegtops extensive survey of blend modes" [1]. The formula given there is exactly the GIMP implementation.
As you said, softlight can be regarded as a smoothened variant of overlay mode which offers softer transitions. Mathematically, this formula describes a linear cross-fade between multiply and screen depending on the base layer value.
best regards, yahvuu
[1] http://www.pegtop.net/delphi/articles/blendmodes/softlight.htm
gimp-developer-list mailing list gimp-developer-list@gnome.org https://mail.gnome.org/mailman/listinfo/gimp-developer-list