Closed jbardin closed 9 years ago
Added another proposed addition, which reads tag values into a bytes.Buffer
so we don't try and allocate a []byte
upfront when the value may be too large.
Looks good. Do you have an image that exhibits the problem that could be used as a test?
(add style changes per bradfitz's comments, and squashed commits)
@rwcarlsen: I have a couple jpegs that can trigger this, but they don't really fit into the tiff tests. I could write them into the /exif tests, or just send them along to you if you want to make some synthetic tests out of the exif structure. Each jpeg is still 173793 after stripping the image down to 8x8. I haven't found a convenient way to write bad exif data.
I agree they should go in the /exif tests. In the past, I've truncated images after the jpeg app1 section to make them smaller. This has worked well since goexif doesn't read beyond it.
On Mon, Oct 27, 2014 at 10:18 AM, James Bardin notifications@github.com wrote:
(add style changes per bradfitz's comments, and squashed commits)
@rwcarlsen https://github.com/rwcarlsen: I have a couple jpegs that can trigger this, but they don't really fit into the tiff tests. I could write them into the /exif tests, or just send them along to you if you want to make some synthetic tests out of the exif structure. Each jpeg is still 173793 after stripping the image down to 8x8. I haven't found a convenient way to write bad exif data.
— Reply to this email directly or view it on GitHub https://github.com/rwcarlsen/goexif/pull/29#issuecomment-60610039.
Added files and tests to /exif
Could you make an ./exif/corrupt
directory and put the images in there? I anticipate the corrupt image collection growing in the future as the exif package becomes more robust.
moved test jpegs into ./exif/corrupt
now also fixes issue #30
Thanks @jbardin!