I agree. it is probably a good idea for a dialog to pop up stating the script only works with a white bg with dark lines.However you could add this yourself in the pop-up blurb that shows when you mouse over it in the menu.


Just a short fix to remind yourself.
You would change it here (about line #343)

Thanks Rod!
I did what you suggested (maybe someone else will do the same...)
btw, another thing about the FlattingTools: I guess the "Flatten" part (first entry under menu Flatting) is useless: I didn't see a use, so to test whether it's relevant to the main part "Multi-fill" I did remove it completely from my copy and tested again Multi-fill: it works alone.
Did I miss something about the use of Flatten? It says "Flattens an image that has been multicoloured", but this is already performed inside the Multi-fill; definitely I should have missed something...Can you help me also on that?

After running multifill you will have 2 layers.
1 colors
2 the comic outline
Select the comic (white and black lined layer) and run Flatten.
This will make little uncolored spots take the colour of the nearest area on the color layer.

Best i can explain it. The Flatten script is written inside the multifill script so you can run flatten from the multifill dialog or the menu link.
Rob A would explain better than i of course.

Thanks Rod,
I did as suggested: it really removes the black lines used as separators for the areas (the black and white layer becomes a white layer); is this the effect also for you or is it there something wrong in my version?
If this is the correct effect, I would say (for myself): use it when you like to see all the coloured areas without separating lines (sometimes, this is better, sometimes not)

The ability to run Flatten separately is provided because Multi-fill provides the option of "flagging" areas that are below a certain size (but larger than "joined" areas). These "flagged" areas are painted in the specified 'Flag color', which permits the artist to manually examine them to decide whether they should be the same color as the surrounding area (i.e., "joined"), or a different color from the palette.

Thanks Saulgoode!
But, as I asked to Rod, is it normal by using Flatten that black separators disappear? Just to know

Hi-

To answer a few questions:

- I wrote the script, which performs similar to a photoshop plugin that someone was looking for in gimp. I don't use it often myself, except for some texture creation. The name "Flatting Tools" comes from what the process is referred to by colourists.

- "Flatten" is meant to remove the black lines leaving only the coloured areas, and as SG mentioned, it is either used directly if selected in the multifill script or is available to be called manually after.

- The script works for me when called on a layer with transparent areas. The script uses the stock select by colour with threshold to select the background area

- There was an infinite loop which could occur if the script was invoked if there is no or very little of the selected bg colour in the image (nothing to do with transparency). I've added an explicit check for no colour, and added a check to detect the infinate loop situation and abort, with a message to run multifill without flatting. (It is a limitation of the built in dilate math that causes the loop).

- I can't reproduce the error "Unable to run GimpPdbProgress callback. The corresponding plug-in may have crashed." What version of gimp is this with?

I've uploaded the fix for the infinate loop to the gimp-plugin registry http://registry.gimp.org/node/14051 but it seems to have appended a _0 to the file, so if you replace yours, make sure the name is correct and the old one gets overwritten.

-Rob A>

RobA, thanks for your attention.
I downloaded the new version replacing the previous one.
One quick reply (other tests will follow):
- the error messages
"GIMP Error
Unable to run GimpPdbProgress callback. The corresponding plug-in may have crashed."
still occur.
Did you load my initial draw on page 8 of this topic and try with that?
I did and I still get those messages (also Odinbc had my same result)
But I reply quickly only about this test because there must have been some other change in the script, so that the output -which was very nice as usual in spite of the errors- now is very poor in colours.
I attach here my new result, so you can verify yourself
(my environment is Win 7 32 bits, Gimp now at 2.8.6, was 2.8.4 previously)

additional tests:
- checked -as you said- that now an image with only transparent areas and black separator lines (typical output of script Pursuit Curve DOES NOT GO ANY MORE into an endless loop, I get immediately a totally black image; thanks for this important improvement
- checked that -if there is some coloured area and not only transparent ones- there is no error, but I get as result what I consider a "strange" output (maybe it's not so for you and other users); so I attach the result for your double-check
(note: I filled with white alternate spaces, I attach here also the input but in the preview everything appears to be white so you cannot see this alternated white-transparent areas
the sections which I filled with white are those that have been correctly filled with random colours by the plug-in

I confirm -through other tests- that with any kind of input, if one of the two "gradient" fill-options is selected, the gradient applied is always black-to-white.
Odinbc, could you double-check, please?

I confirm also that the problem with the fill gradient in B/W applies only to the most recent version.
I was able to get back the previous version, reloaded with a different name not to override the last one, and I got fantastic gradient-fill results.
RobA: before you "hit" me, I've nothing against your script, it produces wonderful results, I'm sincere: All what I put here was -and is- to help you removing some pitfalls because I interpreted the role of a Gimp-Chatter acting also as a tester, so from time to time I perform a kind of "monkey test" on the plug-ins I find here.

Again - what version of Gimp are you using, and what language is installed on your machine?

I am unable to reproduce your issues.

-Rob A>

the last line of my FIRST reply was:
(my environment is Win 7 32 bits, Gimp now at 2.8.6, was 2.8.4 previously)

edit: Odinbc reproduced immediately my problem on messages (probably, he has my same environment)
I asked him to try also on the new version to confirm or not my tests, but so far I didn't get a reply in here

Gimp 2.8.6, Visa32, new v. MultiFill
(with Gradient fill options)

If I run MultiFill after samj Pursuit Curve, error message now,Rerun, unchecking 'Flatten After' result in no error, no loop & a black background.

If I run dinasset test image the result is the same as dinasset's image. Error 3 times, I hope that info helps.

thanks Odinbc!
so it seems this time win 7 32 bits has no responsibility: you Odinbc run Ubuntu 12x
curious to know whether with a partially filled in Pursuit you also get "strange" dilated colours, as me

edit: I read now better, you did the test on Win Vista, not Ubuntu, sorry

Found some time to get back to this.

The image in viewtopic.php?f=8&t=1221&hilit=multifill&start=80#p99780 produces exactly the results I'd expect. The filter uses the identified colour (white) and treats everything else, including transparent areas as "not white" (as this was written initially to deal with scanned art which would have no transparency, typically). A workaround to get the results you want would be to run multi-fill, take the original copied layer and do "Alpha to selection" then invert the selection and on the multi-filled layer hit the delete key to delete the original transparent layers.

I'm changing the script to transfer the transparency of the source layer to the final layer, as this would "make sense" from a user perspective if there is transparency in the source layer:


The error

appears to be a bug with the script-fu display window that randomly(?) occurs when calling "gimp-edit-blend" (as it ONLY happens with gradient modes). It is definitely repeatable, but random, since after adding additional debugging, it clearly happens for different sections even when rerunning on the same image repeated times.

If you runs the script and it causes this error, close the newly created image and rerun the script using ctrl+f (Filters->repeat) and it will run without the error... no matter how many times it is repeated (on my system) which is why I suspect the error is stemming from the gimp script-fu plugin when a script calls the gimp-edit-blend.

I also can't get it to happen from the scheme console, even when calling random fills in a tight loop, which lends more credence to the idea that it is a script-fu plugin GUI issue.

I'm changing the script to send errors to the error-log rather than the pop-up message box to the error is less intrusive.

Attached is an updated version - give it a try please and see if it does what you hope.

-Rob A>

Thanks Rob for your support!
Downloaded and given some tests.
1.using the new version (random colours fill) on a PursuitCurve filled alternatively white/ transparency, gives the desired result (attachment RobATransp)
2.using the new version (gradient fill) on a PursuitCurve completely filled with white gives still B/W gradients, while the (old) Graechan version produces nice random coloured gradients (attachments RobAGradient, GraechanGradient).
Could you double-check? Thanks

Hi. There is an option. To use the fg-bg gradient, or random gradients. I could not remove the regular gradient options, as it is one I use regularly

Try it selecting the "Random" options rather than "FG to BG (RGB)".

-RobA>

OK, thanks Rob.
So far, I didn't change that parameter probably because -by using Graechan version- it is not required (maybe it does it by itself).
Yes, changing that parameter, I get coloured gradients, thanks.
Still one (very small) question: the default parameter says "FG to BG", but that's not true for me: I have BG / FG colours different from Black and White (I have and I tested having Red and Yellow), but if I leave that option the gradient produced is really Black to White, not BG to FG.
So, if this happens also in your environment, better to change the text, maybe...

I took the idea from the Graechan version but changed it a bit, so that parameter is necessary to select random or not.



Thanks for catching that.... I wasn't resetting the colours to the context colours before blending...

Attached is a version with that fixed. If it looks OK, I'll also update the GPR version.

Thanks for the feedback.

-Rob A>