Commit Graph

10 Commits

Author SHA1 Message Date
Andrew Murray
c2189235af Line too long 2018-07-02 19:26:02 +10:00
Hugo
d97e16c903
Merge pull request #3190 from radarhere/mimetype
Added ImageFile get_format_mimetype method
2018-07-01 21:19:57 +03:00
Andrew Murray
c971bac651 Changed mmap file pointer to use context manager 2018-07-01 12:19:30 +10:00
Andrew Murray
dbf899fb78 Removed manual determination of mmap file length 2018-07-01 12:09:23 +10:00
Andrew Murray
6793b5bbd5 Added ImageFile get_format_mimetype method 2018-06-30 21:08:41 +10:00
wiredfool
d173e81798
Merge pull request #3023 from kkopachev/issue-3022
Certain corrupted jpegs can result in no data read
2018-03-21 07:55:17 +00:00
Konstantin Kopachev
1e9e64c8b0
Move jpeg-specific eof-processing to jpeg plugin 2018-03-06 22:52:08 -08:00
Andrew Murray
f22f1628eb At least two spaces before inline comment 2018-03-04 21:36:33 +11:00
Konstantin Kopachev
add2746ac6
Certain corrupted jpegs can result in no data read
On truncated jpeg, decoder can suspend waiting for additional bytes in
buffer. For some input files, decoder suspends on jpeg_start_decompress
stage. If at this point file reader reaches EOF, py code never gets back
to jpeg decoder and we end up with no bytes to result image. This leaves
us with some amount of potentially useful bytes undecoded and thrown
away.
Libjpeg docs suggest that in such situation, more appropriate would be
to add EOI marker to the end of buffer, which will allows decoder
to finish. https://github.com/libjpeg-turbo/libjpeg-turbo/blob/0dd9a2c1fd6c/libjpeg.txt#L1803-L1809
Docs also mention that adding EOI markers is what non-suspending code
does anyway.
2018-02-28 22:15:58 -08:00
wiredfool
0bb3f4fee9 source layout reorg 2017-12-28 14:49:47 +00:00