How to stop Asperity from remapping pixels

Sorry, this is a bit of a long post / rant :hot_face:
I’m not sure if this is a bug or not, but this is quickly becoming a show stopper for me to continuing to use this program as I can’t trust the output from the program.
I’m working in index mode using 16 palette’s of 16 colours (for a tile map page).
I need to be able to reuse the tiles, but using a different palette.

For example, master tile set uses palette 0. I want to reuse these tiles, but using a different colour palette #6.
In my mind I should be able to open another page in Aseprite copy the whole palette across (all 255 colour / 16x16 palettes).
Copy the master tile set I want over to this new page.
Recolour this tile set using the palette I want (so going from pal#1 to Pal#4 - normally a darker version of the same palette). I blank out Pal#1 just to be perfectly sure that the new tiles don’t reference Pal#1 at all.
I then copy this new tile set back to the original page and move it into any empty space on that page.
Now in my mind it should still be using the new colours (Pal#4), but because there’s duplicate colours in the whole palette / colour index, Aseprite remaps the the tileset using the same colours it finds in the whole palette. Making my recolouring work useless. This is without me hitting the Remap button at any time.
Is there something stupid I’m doing wrong here as I’m sure I used to be able to do this (maybe an issue with V2.17)?

So if I use a new layer instead of a new page, it doesn’t auto remap it then as it’s still in the same file.
So not sure if this is a bug or a feature…

Forgive me if I’m wrong on this.

You want to recolor an image with a different set of colors, correct?

Wouldn’t you just put the new colors you want somewhere into the 256 color palette and drag them around to drop the colors you want into the desired index position? Say, you want to change index position #3(green) to a brown color. Drop brown into a blank index(let’s say index position #40 is (0,0,0), thus “blank”), then drag it to index position #3, and remove or reorder the green(now in index position #4) to get the other colors(that were #4-15, now #5-16) back to their original index positions(#4-15)? You could then save this new image and palette as a new Aseprite file.

That’s what I was trying to do, but it seemed to have stopped working. I’m sure it worked before. Maybe I’ve just missing something, but it was a really quick way to also recolour the sprites to use the new palette.
What I used to do was basically copy the original palette and sprites to a new page, paste the new palette over the old palette so it’s recoloured the sprites.
I would then increase the colour palette and copy the new colour palette to the correct location in the colour palette(32-47), remove the original colour palette(0-15) and make sure every other colour was a colour not used in the sprite. and then hit remap. This would force the sprite to use the new palette location.
I would then copy the new sprite back into the old page (making sure the new palette was set up in the old page). But for some reason, it started to auto remap when I imported the new sprite.

So what I’m doing now is.
Colours 0-15 (Palette A bright reds for example).
Colours 16-31 (Palette B - dark - bright reds - some colours been the same values as first palette A)
I would copy the sprites I wanted to recolour to palette B and past them into a new page (which was the mistake) as when I copied them back, it would auto remap the colour going from colour 0.
By recolour I mean mask each colour used in the sprite and draw over it with another colour (so colour 0 would by 16 and so on).
If I did this in a new layer it works fine.
So it seems that Aseprite remaps when importing gf/x from another file. Of course I could just of been an idiot and didn’t set something up correctly - it wouldn’t be the first time =)

Hmm… I’ve tried copying/pasting sprites, recoloring, rearranging palettes, etc., and I can’t seem to find an error. The only thing I can point to is that you said some of the color values were the same, and I was reading a few days ago that Aseprite has some trouble if there are duplicate values.