This is an enblend bug. Enblend sometimes takes along pixels from the "black" (but alpha=0) pixels outside the remapped area.
The question is what enblend can do about the "wraparound" area. For a good blend, it needs access to pixels "beyond the edge".
(for storing as a cylindrical projection image, it doesn't really matter that much, but as postprocessing people might want to put it in a VR tool or something where the seam at 0/360 or -180/180 becomes important. )
Anyway, The only thing I can think of to fix this easily would be for Nona (or other remappers) to generate an output image canvas from -190 to +190 and then later cropping at -180 - +180. (i.e. duplicating pixels between +170/-190 to +180 and from -180 to -170 (+190).
This is an enblend bug. Enblend sometimes takes along pixels from the "black" (but alpha=0) pixels outside the remapped area.
The question is what enblend can do about the "wraparound" area. For a good blend, it needs access to pixels "beyond the edge".
(for storing as a cylindrical projection image, it doesn't really matter that much, but as postprocessing people might want to put it in a VR tool or something where the seam at 0/360 or -180/180 becomes important. )
Anyway, The only thing I can think of to fix this easily would be for Nona (or other remappers) to generate an output image canvas from -190 to +190 and then later cropping at -180 - +180. (i.e. duplicating pixels between +170/-190 to +180 and from -180 to -170 (+190).