Image driver selection

[mukoki]

Image reading is supposed to choose the first driver which can successfully read the image, but actually, it fails even when some drivers can do the job. Example Only a few drivers can read BigTiff

• Referenced Image (Image IO Tiff Image reader, version 1.0, ImageIO-Ext)
• Buffered Image (Commons Imaging) [thans to commons-imaging alpha-4, added today]
  But if one of these readers are not chosen explicitly, importing the image fails (attached a small BigTiff image)
  BigTIFF.zip

With jp2 and the new driver, it is a bit different : older drivers display a blurred image, but does not throw exception, the new driver has no chance to be called.

[edeso]

Image reading is supposed to choose the first driver which can successfully read the image, but actually, it fails even when some drivers can do the job.

not sure that is what is implemented. afai recall we offer drivers claiming to be able to decode in an order sorted by a preference value we set, so we can make some to be the preferred.

are you sure the implementaion is supposed to bruteforce try in the preference order?

[mukoki]

Yes there is a preference order defined somewhere but i don't remember if next driver is searched when the current one is not found, or when it fails or what...

• also I'm not sure that drivers order in the UI is the same and it is not very easy to understand what the real behaviour is.

[edeso]

quick search. i'd say it was this priority setting

https://github.com/openjump-gis/openjump/blob/HEAD/src/com/vividsolutions/jump/workbench/imagery/ReferencedImageFactoryFileLayerLoader.java#L248

[mukoki]

OK, was changed on april, 10