Menu
▾
▴
#511 CropWarp raster plugin can't overload existing file
If one process an image with CropWarpPlugin and try to save the result with the name of an existing image (want to replace the former image), there is no warning as in other plugins, and it produces a weird image (looks like a mixt between the old and the new image).
I try to reproduce the problem this morning, but after I get a NPE in roughly similar conditions, I now try to describe the problem precisely, step by step... and the problem vanished.
I'm quite sure there are some conditions producing weird results or NPE, but it may not be normal conditions. Sorry for the noise, it will need more tests before I can describe the problem in a useful way.
maybe it's related to memory usage? ..ede
Maybe. I think at least NPE was a bug left in a recent commit I did. For other remarks, I really must repeat the process step by step.
I was able to reproduce the bug. The warning message comes out but the output image either is not saved or it has a wierd look. I will give a look at the code on this weekend
The bug seems to happen only if user tries to overwrite the input file.
One possible (hard) solution seems to make RasterImageLayer framework able to store modified datas into memory and give up to output file option into the dialog(s).
This seems to hard to work around that generates other problems to solve (warning to user to save layer when a project is closed, etc).
Another fast solution is am considering to extend EnableCheck of save-file action: actually it checks only if the field to put output file is empty (if so, the process is stopped with a warning). The extension will also check if output file is the same as input file.
I don't see other solutions in this moment
I am for the fast solution as it makes impossible to cancel/modify original data
I did further tests and observed something strange which may be related (or not) to this bug.
I crop an image and save the result in a new file, it creates a new RasterImageLayer.
I remove this new RasterImageLayer from the LayerNamePanel : the underlying file stay locked
Now I remove also the original RasterImageLayer : now the file containing the cropped image is unlocked !
I tried to close a few streams and RenderedOp in TiffUtils2, but nothing fixed the problem.
I also think that the big cache in TiffUtils2 is not a good idea as it retains GeoReferencedRaster in a static Map (i.e for ever), but I tried to clean this cache in RasterImageLayer.dispose() and to replace the cache by a WeakHashMap : nothing solved the locking problem.
I added a check in order not to overwrite input raster file with the new one. This patch together with Michael's unograde should avoid to have strange output, I hope
Thank Peppe,
I let it opened as it may probably be fixed in a better way, but it can be postponed to version 2. Currently, a first dialog ask the user if he wants to overwrite the existing file. If yes, the user is informed it is not possible.