Travis fails
.PHP Fatal error: Call to a member function addAttribute() on a non-object in /home/travis/build/joomla/joomla-cms/libraries/joomla/form/fields/imagelist.php on line 53

Just fixed, also on Tracker

It's actually much easier. Just change the getOptions method to

    protected function getOptions()
    {
        // Define the image file type filter.
        $this->filter = '\.png$|\.gif$|\.jpg$|\.bmp$|\.ico$|\.jpeg$|\.psd$|\.eps$';

        // Get the field options.
        return parent::getOptions();
    }

No need to do anything in the setup method.

Note that instead of using $this->element->addAttribute() the filter is just directly assigned to $this->filter

Yes, it would also work, but I like much better to setup field with correct filter

Keep in mind that the formfield may be extended by 3rd party extensions and this could possibly break them depending on what they do with it. Not likely, but still possible imho.

Both approach can break. If someone would redeclare filter in XML or set in setup method, then your case would also override filter

If someone would redeclare filter in XML or set in setup method, then your case would also override filter

The imagelist never supported setting the filter in the XML. It's meant to be hardcoded. If you want to set the filter, you use the filelist formfield instead.
You have to make the PR so that it can't break anything, otherwise it can't be merged.

Could you give an example how it could breaks something, because I do not see that.
I Just set attribute filter before parent FileList field would setup it.

Actually, it behaves completely wrong currently and still will partially after your patch.
The imagelist field is supposed to show a list of images with a hardcoded file extension list. Currently, it shows everything except if you provide the filter in the XML (which will trigger a PHP warning). This are basically two bugs.
You are fixing the first one but still allow to set a custom filter, which is still a wrong behavior.

Could you give an example how it could breaks something, because I do not see that.

I don't know an example, but I know people tend to do crazy stuff
If there is no reason to even potentially break something, don't do it. Why would we want to move the call to another place? We need the filter in the getOptions method and only there and it was there since a long time.

I have get back to your suggestion which was also my first try before I submitted PR.