Will it allow me to apply those changes as a patch to the ROM? So I could play them on a DS/3DS or other systems' emulators? Thanks
I've never messed around with ROM hacking myself, which is why I'm wondering if there's an application for simple color correction or filters, but I will give these a try, thanks.
GBA palettes are software defined (no more prebaked list of colours you can feed an emulator* or something) and frequently altered at runtime for purposes of colour correction, certain types of shading effect, simple animation, more complex animations and other such purposes. Not to mention there are multiple graphics modes with slightly different takes on palettes if you want to view it that way (
http://www.coranac.com/tonc/text/video.htm http://problemkaputt.de/gbatek.htm#lcdcolorpalettes https://www.cs.rit.edu/~tjh8300/CowBite/CowBiteSpec.htm#Graphics Hardware Overview ).
*said emulator might have the option for filters of certain types. This will be for PC though as most ones for embedded devices have limited options here, and terribly unlikely to do anything on hardware.
To that end the only point and click palette editors you will find will be for individual games that people have gone in and fished out the location of. Not everything uses animations or has correction options and you can get pretty far by searching the ROM for the palette as you snatch it from RAM/savestates, often even with ones that see simple animations you can still use snippets of it (if like Mr Driller 2 it is just the one colour that gets cycled for rainbow blocks then the static aspects of the palette will likely be there somewhere).
If the simple methods already covered are not doing it for you and if you absolutely must find it for a given game, and it is one of the more complex types (be it from animation, generation or compression), then be prepared to have to go full bore ROM hacker, or consult one. It is not usually a massively complicated affair; it is not like you are spotting subtle bugs, optimising code to fit something else in, expanding the scope of a game in some weird way, or watching an algorithm play out to create something like
https://www.dragonflycave.com/mechanics/gen-i-capturing the likes of which tend to need some measure of familiarity with assembly coding. It is then usually just a matter of getting to a point just before the data you care about is loaded into the palette section**, making a savestate, telling the emulator to break on write (by the way the guide is for vba-sdl-h but these days most would suggest the graphical no$gba debugger
https://problemkaputt.de/gba.htm , the logic behind the actions it takes though are the same between emulators here, and for that matter most other debuggers you will likely ever see), then either looking back up to see a nice read (might be the CPU read, might be BIOS related, might be DMA) that fetched it from the ROM or repeating for that until you get back to a read of that data from the ROM.
**many emulators will have a palette viewer and you can select "update in real time". Usually though if you can get into another room or just before you start a new level/minigame/battle and maybe step out of a menu then you will be at a point where it swaps a palette in or out.