Closed A-Kurimoto closed 6 years ago
I just found the same bug independently. I have a JPEG image already stores as a BufferedImage
- it has a ComponentColorModel
with 3 components. All I want to do in this step is to rotate it according to Exif rotation, so I apply the rotate filter and want it back as a BufferedImage
for further processing. But, this process returns a BufferedImage
with a DirectColorModel
with 4 components. This causes problems further down the line. The source BufferedImage
is of type 5, while what is returned is of type 2. This can't be intentional?
Thanks a lot for a great lib, but it seems like I'll have to do the rotation "myself". I guess I can write a custom filter and use that.
This should be very easy to reproduce, what I do is very simple:
bufferedImage = Thumbnails.of(bufferedImage)
.scale(1.0d)
.addFilter(ExifFilterUtils.getFilterForOrientation(orientation.getThumbnailatorOrientation()))
.asBufferedImage();
net.coobird.thumbnailator.filters.Flip
has the same problem.
@coobird Is this library dead?
@Nadahar, I haven't had much time to work on Thumbnailator for a quite while. In the past couple weeks, I have been preparing a new release with some bug fixes, which I hope to get out soon. (Trying to make an environment to verify that Thumbnailator acts properly with different JREs proved to be more painful than initially thought.)
I'll create a new issue of the bug you encountered so that I can keep track of it. (The BufferedImage
type thing turned out to be a mess in certain situations, so I'm thinking of changing how that works in a future redesign of Thumbnailator.)
@coobird That's good to hear. It's a nice library that makes working with ImageIO
easier. I "solved" this issue by overriding the classes in the meanwhile, but it's obviously a less than ideal solution.
I have encountered the bug that some JPG picture was collapsed when I execute rotate(angle). How about of using the default image type?