MmmMaarten

That question should be irrelevant, because we are merging the child layers, not the parent.

When having visible image layers selected, but the parent group layer is invisible, and using 'Merge Selected' the result is an empty layer. While expected is to get a layer with the merge of the selected visible image layers.

@thomaso I'm surprised I got a response on a message I had hidden (because I couldn't remove it from this forum). Does this mean that you can still see the message I hided (while not even I can't)?

It is solved. Please see the post above yours. Thanks for trying to help!

Hey, you're right. I tried that several times and was sure I didn't see a change, but when I retry that now on some layers I see it working now. Wow. Thanks for being consistant!

?

This is not very helpful. I just told you they are already rasterized and trimmed and rotated afterwards. That's the situation I'm in right now. Not the ideal situation, I know, but it's like this and I cannot change that now. If you have a workaround for this as my opening post writes I'm all ears.

@GarryP We already know what is happening. Please read my previous post. It's exactly that.

Sure, in an ideal world, if I would've known I would rotate them afterwards. But I didn't at the time.

Thanks for your response Garry. I tried rasterize and trim, but it doesn't trim any more than it already had trimmed before. The issue here is that the straight bounding box is calculated after the rotated boundingbox: This is an issue, because before it was rotated, the rectangular bbox needed more transparent pixels, than it would now with a straight bbox: I never send production files, but I can assure you that there are no semi-transparent pixels there. All these parts are carefully masked and rasterized and trimmed after that before these were rotated. The real solution here IMO would be that Serif fixes/adds a way to have the right boundingbox after rotation. It's now calculating the bbox after the rotated bbox, but that's a wrong assumption and is causing way too much space around. Instead IMO it should recalculate the bbox to the actual non-transparent pixels or give us the option to do so. But because that's not currently possible I'm looking for a workaround that doesn't involve me having to correct 400 individual layers all with the lasso tool and a 'rasterize and trim' after that. Do you perhaps know of any workaround to do such a thing? If I could create a macro to select the outer fully transparent pixels that would already be helpful, because in the same macro I could add a mask to that layer and trigger an rasterize and trim. But it's hard if not impossible to use the flood select tool for all these layers as they all are different in size etc. Hope this makes sense

Hi, I have a few hundred rotated layers which were trimmed exactly before, but because of the rotation now have transparent pixels around their borders because the bounding box doesn't really fit tightly no more because of the rotated bbox. I would like to strip these transparent pixels off to export the images as small as possible trimmed, but that's a lot of work to do manually. Is there perhaps any way in Photo to trim layers to the smallest rectangle (bbox) around the actual pixels that aren't transparent? Or better to solve the actual problem: Is there a way to have a straight boundingbox on an image layer that actually fits the non-transparent pixels after rotation?

Cool! This works fluently and easy! Great find I'm gonna make a macro with ungroup and group and fire it on all my groups now. Nice trick to know!

Thanks @thomaso and @RE4LLY, those are super useful additions. A little bit dissapointing that the bug seems to be known for quite a while now without fix, but at least it's known. I will try it with ungroup and group. I didn't even know there was such a thing as 'ungroup' in the menu. That's a very convenient option and way faster than to drag all the children out and group them again. Great tip! Thanks again

Alright, than I guess it is what it is for now. Let's hope it will be possible in the future. But luckily at least we can correct the bbox now. That's super nice! Thanks again

Yeah, I know about symbols, but I think that's way overkill for this workflow. Symbols are more for creating a library of objects to reuse them, while what I refer to here is to have just a linked/referenced copy of every single part in the same file. Duplicate Linked is perfect for this use case, but we only need to have more features to be able to make it less cumbersome / time consuming to use it on 300/400 layers and layer groups.