IrfanPaint Support Thread

[Bhikkhu Pesala]

F12 will both open and close IrfanPaint. Escape to exit can be turned off in Properties.

[son-of-a-gun]

Paint dialogue

When the paint dialogue is open, text can be inserted when the pointer is pressed, but it's not possible to undo the insertion.
To exit the dialouge, it feels most natural to use ESC, but this exit the proram itself unfortunately.

Like MS paint, it would be very nice to be able to move marked areas (and why not copy/paste the area)

This paint dialogue is a very, very good feature

[Sam_Zen]

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

[hiker_jon]

Flood fill bug

Hi,
I wrote the following before I found previous posts on this subject:

I have compared Irfanview Paint flood fill with Paintshop Pro and the Gimp. The other programs do much better on a jpg file I have used for testing. I think they have a tolerance for slight differences in color in the fill area. As it is the Irfanview flood fill is useless on jpgs (by far the most common image type).

After reading the other posts I see that this problem has been reported and discussed. I will just make an additional comment: Other paint programs have found a solution to this problem with flood fill on jpgs. Perhaps you can try checking with the Gimp developers to see what they have done.

[matera]

The clone is acting up. First of all, it bothers me that I can't be sure if an area is being selected. Then the cursor gets erratic, changes unpredictably. Finally, after working in one area, I (left)clicked on a spot some distance away (on a zoomed in pic) and a ragged offset streak appeared between the new position and the old, like a strip of image that skidded 20 pixels over after being cut loose.

It is way past my bedtime, so I will have to postpone further observations and specimen capturing

PS it is the b0.4.7.51 version

[MItaly]

I wondered: Why, if the toolbar is magnetic now, would it be still necessary to save its previous position in the INI-file?

Because even if the user doesn't want to make the toolbar magnetized, IP will anyway put it where the user left it.

I can't make a random selection appear by playing with the bucket fill, but I have found some odd interaction between it and a selection.[...]

I found the problem and I will correct it in the next release.

Can the paint plugin have any influence on this sequence of saving from the clipboard, or is this all just iv's behaviour?

I think that it's IV's behavior. IP doesn't interact with files, it just works on the DIB loaded in memory.

[matera]

IV always reverts to the non-saved image, whether it is a clipboard paste or something that has been opened and altered. This makes it dangerous not to have a warning when saving - it is all too easy to make one more little change, then just "save" instead of "save as" and overwrite the original file.

A clipboard paste that is altered has a tenuous ghost-like existence. Only IrfanView knows that it is there. Once it is saved as a real file, the real file is definitely on the hard drive - but the image in IV's window is still a ghost.

I have never had a problem with losing something that was saved-as, but it is important to remember that the save-as and save directories are not the same. Sometimes I have a hard time finding something again because I forget where I last saved-as to and just do it without looking.

[jsc37227]

Sorry to have stirred things up. I don't have a lot of time to investigate.

This whole "save as" behavior has caught me off guard. In trying to investigate this random selection occurance, I tried to recreate the steps of pasting, save-as, editing, etc. More than once, when I quit irfanview, the image I thought I had saved was gone, nowhere to be found - even in the temp and apps subdirs in the user directory. It seems one problem with iv is that when you do a paste from the clipboard, then a save as - you better close the file immediately then reopen the saved file.

Can the paint plugin have any influence on this sequence of saving from the clipboard, or is this all just iv's behaviour?

[matera]

I can't make a random selection appear by playing with the bucket fill, but I have found some odd interaction between it and a selection. Other tools work smoothly within a selection. The fill tool and the selection act like they are trying to avoid each other, as if they had magnets attached and I was trying to push identical poles together. The bucket cursor changes to the magnifying glass of the normal IV selection (no Paint) and the selection skids around. The area that is filled matches the area of the original selection, not the slewed-over one. It is hard on the nerves! It also ruins the selection, so that it would have to be restored from the Custom Selection dialog if one wanted to keep on working in the same restricted area.

[Sam_Zen]

Can't reproduce it either.

But I wouldn't be surprised if the 'clipboard' status has something to do with this.
One can monitor this behaviour in the titlebar. An executed save as JPG, still will show 'Clipboard'.
Not the name of the new JPG. So if one edit some more, it's unclear what's been edited really.

IP plays a role in this too. I created a clipboard situation by making a panorama image. Did F12.
Then I used the FloodFill tool to test jsc37227's bug. When done I saved as test.jpg.
Titlebar still saying 'Clipboard'. Then a F12 to close IP. Titlebar suddenly says '*fullpath\file'.
But if I minimize IV and then bring it on screen again, the title bar says 'Clipboard' once again.
I tested more variations in the sequence of actions, but the conclusion stays quite fuzzy.
Of course one could close IV after the save, and open the new JPG again, but that's not the point I think.

I wondered: Why, if the toolbar is magnetic now, would it be still necessary to save its previous position in the INI-file?

[MItaly]

Hmmm, I tried for two minutes but I didn't manage to reproduce it... anyway, I'll keep investigating (I have already an idea of what part of code may be bugged).

[jsc37227]

One more item as I was just using the paint bucket tool. After a random number of clicks filling in various areas of image, 2-8 clicks - seemed to be random, a selection rectangle would pop up out of nowhere. Never seemed to be the same shape, either. At first I thought I might have done something, but then I was careful and it continued to pop up several more clicks after clearing it.

This was a little convoluted, but I started with a clipboard clipping of a 2-bit tif image; opened i_view and pasted the image;
did a "save as" to a compressed 2-bit tif image;
realized that if I wanted to add color that I had to increase the color depth;
so did a save as to a jpg;
THEN I started to used the paint bucked tool.

I must have been still working with the clipboard image, but with the increased color depth from my "save as" to jpg.

I couldn't seem to duplicate the steps, so this is not much help, I realize. Maybe someone else will run into it??

[MItaly]

Actually IP doesn't check if the toolbar goes off-screen with the settings written in the INI file; I'll add such check in the next version.
Thank you for the feedback.

[jsc37227]

Again, thanks for this tool.

I did just notice one quirk when trying out the '0.51 update. I run a 1280x1024 screen size on my laptop in the docking station with an external monitor, but the internal resolution is 1024x768. When I was out of the docking station last night, I hit f12 to activate the plugin, but it was nowhere to be seen, because the last time I had i_view running was at the higher resolution. The only way that I seemed to get the paint toolbar to show was to quit i_view, open the i_view32.ini file and find the TBXPos value in the Paint section, and make it a smaller number. The toolbar way "way off to the right" of my smaller screen size.

I might have missed an easier way to get the toolbar to show, but this was the only thing that worked that I could think of at the moment.

[MItaly]

Now the undo works as it worked before the b0.4.7.50; the problem with the previous version was that the paintbrush-like tools didn't save a new undo image.