IrfanPaint Support Thread

[Sam_Zen]

Just too much issues in one post..

[bwwd]

I have questions...
It would be possible for clone tool to work with transparent color ? you know when you pick up your second color to eg.purple then it doestn clone this color.
When editing photos then some smooth aliasing between pixels would be great , cause now its sharp so its visible when youre trying to use it on photographs.
Also would be nice if pain could immediately change itself to paintbrush tool after you pickup color with color-picker(or to previous used tool).
It would be good if we could use color-picker when we editing palette of the file .That are my suggestions.I like the program keep updating it

[Leif]

Normally, I navigate in a dir while viewing by pressing space and backspace.
I wonder why this is disabled as soon as IrfanPaint is active..

Some time ago I asked this question and got this answer:
"...it is not a bug, it's a feature that some people asked me to avoid the risk of losing the work done with IrfanPaint by pressing Space bar/Backspace for accident. I think that in the final version I'll make this feature optional, i.e. the user will be able to decide if it must be activated or not."

[Sam_Zen]

Normally, I navigate in a dir while viewing by pressing space and backspace.
I wonder why this is disabled as soon as IrfanPaint is active..

[Frank]

In these case:
Sorry for this question!!!

(You are right: It's a malfunction of IrfanView!)

[Sam_Zen]

(I dare to reply, because I suppose MItaly would answer likewise)
You say it yourself : the "Undo" function of IrfanView.
So this is not a matter of IrfanPaint.
A discussion about a multiple Undo has been going on in the Request department.

[Frank]

"Undo" function (0.4.7.52 beta)

Hello MItaly,

If I'm using the IrfanPaint plugin,
why isn't it possible to use the "Undo" function of IrfanView for more than one step backward?
With (nearly) every other program this is possible!


regards

Frank

[MItaly]

IrfanPaint b0.4.7.52 released

The new IrfanPaint beta release just fixes this bug (and some other UI-related weirdnesses of the tools).

[matera]

Some people just gotta... - BTW, the floodfill was acting strange again today. It happens if I try to work in a zoomed selection - or a selection in something zoomed. I think that must have been what I was doing (half in my sleep) the last time.

[MItaly]

If I had wrote the floodfill code it wouldn't be difficult to add the tolerance: it would be as simple as change a line like this:

if(srcPixelColor==scannedPixelColor)
    //...

to something like this:

if(SimilarColors(srcPixelColor,scannedPixelColor,tolerance))
    //...

//...
inline bool SimilarColors(COLORREF firstColor, COLORREF secondColor, int tolerance)
{
    //here some simple code that do the comparison
}

.
The problem is that I haven't wrote any floodfill code, actually I just use the Windows GDI ExFloodFIll, so I haven't anything to work on; I should implement a floodfill function from scratch, or reuse some code found on the net (the easy way ); the problem is that any code I found is thought to work with some particular classes (e.g. MFC, CDibSection, ...), and I should adapt it to work with my classes, a boring and error-prone work. Anyway, don't lose your hopes: this function is one of my priorities (along with a decent text function), and I'll start to work on it as soon as I will have fixed all the issues of the new object-model of the tools.

[Sam_Zen]

4. 'Comparison' was indeed the wrong expression.

[hiker_jon]

Some points

1. You present this as a hard problem, yet most other paint programs have found a solution to this. It is not as hard as you seem to think it is.
2. This has nothing to do with neighboring pixels. For each pixel you get the RGB values and check that max(max(abs(R-R0), abs(G-G0)),abs(B-B0)) < T.
3. The above check is reasonably fast on a modern computer.
4. Every comparison on every computer is true-false. Your statement is nonsense.

Right on. A tolerance will mean that with every single calculation about a single pixel, neighbouring pixels have
to be part of the formula as well for the resulting values. A comparison instead of true/false.

[Sam_Zen]

Right on. A tolerance will mean that with every single calculation about a single pixel, neighbouring pixels have
to be part of the formula as well for the resulting values. A comparison instead of true/false.

[matera]

It has nothing to do with the file format, doesn't matter if it's a JPG or anything else. The selection is made on the bitmap image loaded in memory, not the file itself. Selecting a single color is different from selecting a range of color, more complex.

[hiker_jon]

A better option

My guess is that other paint programs detect a jpg and set a tolerance accordingly.

I don't think it would be hard to implement a better flood fill: have a tolerance preference, d. Let the user set it. Then check if the r,g,b values are within d of the original color. If d is 0 then use the original routine.

2 hiker_jon
This is not a matter of a solution, it's a matter of options.
The flood fill of IP doesn't have the variable 'tolerance', so it only searches for neighbouring pixels with the same RGB value.
So indeed, it will be quite useless with full-color photo's. But quite useful in other circumstances.

2 matera
Couldn't reproduce the clone problems. using b0.4.7.51 as well