search

dragon66 / icafe

Java library for reading, writing, converting and manipulating images and metadata
Eclipse Public License 1.0
204 stars 58 forks source link

TIFFTweaker.splitPages doesnt release the images #18

Closed oscar-dario-pabon closed 9 years ago

oscar-dario-pabon commented 9 years ago

Hey,

I need to make a split of a Multi TIFF, but later move the Single TIFF image to other folder, even the Multi TIFF. But the problem is tha tthe lib doesnt release some of the Single TIFF and the Multi TIFF.

I check the source, but I cant find any reason.

Thanks.

dragon66 commented 9 years ago

Hi @senneko, thanks for trying "icafe".

The problem you mentioned could be caused by the fact that neither RandomAccessInputStream nor RandomAccessOutputStream closes the underlying Input or Output stream when you close the random streams themselves. The reason for this design is sometimes we need to wrap the input or output stream for a while and hand back the underlying stream to the initial creator to do further work with normal stream.

That said, I checked about the relevant code inside TIFFTweaker and around line 2854, I wrapped a FileOutputStream without giving it a name and later closing it. I believe this is why the output split images were not released. As for the input multipage TIFF stream itself, you need to explicitly close the underlying stream after the split process since it is created outside of the splitPages() method of TIFFTweaker, it is not a good idea to close it inside there.

I have made some changes to the splitPages() method and now it should work. I will check in the changes soon and you can try again.

Let me know if you still have problem with it.

dragon66 commented 9 years ago

Update: also added a closeAll() method to RandomAccessInputStream and RandomAccessOutputStream to close internal streams as well as the random stream itself. Now we can close all the streams in one call as needed (in the case we don't need the underlying stream to remain open after we close the random stream). This kind of implementation does not completely conform to the Java IO stream contract, but I haven't found a better way to do it.

dragon66 commented 9 years ago

OK, there actually is a better way to do it and I decided to take the responsibility to make it conform to Java IO stream contract . Users now don't need to worry about the dangling open stream anymore. I ended up added a shallowClose() method to close the random access stream and leave the internal stream open if needed. The closeAll() method added a while ago is now replaced by the normal close() method. This also makes it easier for the user to use Java7 try-with-resources statement.