maybe I'm again missing something, but let me tell you, David, some doubts on -for me- unexpected results from your Pack Sprites (very very nice!) filter.
Let's take a base image (BG + mask), such as this one:

(text is shown as white but it's really transparent)
Let's take a lot (26) of sprites to load as layers on top, like these:

Now I run Pack Sprite with the following parameters:
pack_sprites 10,10,0,-7,7,1
as you see, I set angle=0 for this first test (-7 as spacing to let letters overlay each other)
I get the following result (nice)


now, let me continue with the next post...

with this second test, I want to see how spaces can be filled using "any angle"
thus I run the filter with the following parameters
pack_sprites 10,10,3,-7,7,1
as you see, only the "angle" parameter has changed from 0 (do not change sprites orientation) to 3 (manipulate sprite orientation using any angle)
here the surprise, this is the outcome:


is there a bug?
thanks

to complete the info for David:
also using option 1 or 2 (180° or 90° angles) the text area in the outcome is either totally empty or showing 2 or 3 sprites

Mask has to be 100% rigid (0 or 1) for starters. Also, if it's a flat mask (black and white) it cannot have any transparencies (alpha channel).

I don't understand you Lyle.
What has to do what you say with the different behaviour of the filter selecting "no angles" or "any angle"?
The BG / mask is always the same.

Guess I read too fast dinasset. Haven't played with the no angle option that often.

Another program you can try is PikPak. It's free and apparently will stay that way since the business model Johnny decided to follow is for selling object packs (and you don't need to use those packs; you can make your own). I did purchase several packs to help support the program, but Johnny's not had an update for a few years now. It's still worth it though and I do occasionally still use it. It allows pretty precise angle control too.

viewtopic.php?f=22&t=8042

yes, I remember you mentioned that (and I also tried it, very nice), but my objective -as far as possible- is to stay in the Gimp+G'MIC world.
From time to time I write filters and I access available functions in there.
Currently I'm experimenting that G'MIC filter and noticed that inconsistency, so I wanted to ask David whether there were a bug (if I remember correctly, David added the possibility to use different angles of positioning to his initial filter, so maybe some "piece" of the modification/enhancement contains a bug...).

not to multiply Topics I insert here a subtopic: PERFORMANCE still relatively to this G'MIC filter:
in case you David open the code to check whether there is or not a bug related to the "degrees", could you just get an eye whether it could be possible (maybe not) to improve performances?
on my current PC (not a bad one, Intel Icore5 with SSD as primary disk) I get the following results:
-input is the same image as per initial topic, but the set of sprites is composed only with 9 flowers
-test have been made with 3 different image sizes: 500, 1000 and 2000
to get the outcomes the elapsed times were:
- 45 seconds on the 500 image
- 210 seconds on the 1000 image
- 995 seconds on the 2000 image
results were all very nice (I continue using the 0 degree option, to avoid problems)

NOT SOLVED in new release 1.6.7

same image, same sprites, same set-ups

result using degree=0 (OK, as before)


result using degree=any (BAD, as before)


Performances: very slow (as before)

I suspect your letters to be too big.
When I reduce their size before applying the filter, it works for me.
Also, the filter is slow indeed, because packing is a quite difficult problem and you cannot get an easy solution without a lot of iterations.
I don't think I can do anything about it.

your suspect is quite reasonable, even if the size is not so big (150*130), but my question stays there:
- why does it work properly if I choose degree=0 and not if I choose degree=any?
the size is the same, the parameters also

edit: my "suspect" is still on the code added to implement the "any degree" function, on request of some user (I guess Lyle); the "original" code - which works with "0 degree" - behaves properly
don't you have the same "suspect", David?

David, maybe I discovered the problem in the algorythm:
- the parameter "minimal scale %" is NOT taken into account when selecting "all degrees", while it is appropriately taken into account when selecting "0 degrees".
New test:
- as a base image just a squared hole (440*440) surrounded by a frame (image 640*640)
- as sprites a series of letters (only a few) with a quite big size (300*261)
- parameters: 10 numbers of scales, 10 minimal scale %, mask as bottom layer

Test1: option "0 degrees" : excellent outcome, sizes have been appropriately reduced to fit in
Test2: option "any degrees" : outcome with just one letter, NOT rescaled

Attachments:
- outcome of Test1
- outcome of Test2





hope this info can be useful