Resolve "GIF loading seems to be completely broken"

Closes #26 (closed)

I think I have now fixed the reading part, but writing still seems to be wrong...

Oh, I see, what the problem is. In our implementation, we quantize pixel values: https://gitlab.idiap.ch/bob/bob.io.image/blob/master/bob/io/image/cpp/gif.cpp#L548 even when this is not necessary. Hence, each of the pixel values lose their least significant bits:

>>> i = bob.io.image.load("bob/io/image/data/test.gif")
>>> print i
array([[[ 18, 253, 255, 255],
        [255,   0, 255, 255],
        [255, 255,   0, 255],
        [255, 255, 255,   0],
        [255, 254,   0, 255],
        [255,  49, 253, 255]],

       [[ 18, 253, 255, 255],
        [255,   0, 255, 255],
        [255, 255,   0, 255],
        [255, 255, 255,   0],
        [255, 254,   0, 255],
        [255,  49, 253, 255]],

       [[ 18, 253, 255, 255],
        [255,   0, 255, 255],
        [255, 255,   0, 255],
        [255, 255, 255,   0],
        [255, 254,   0, 255],
        [255,  49, 253, 255]]], dtype=uint8)
>>> bob.io.base.save(i, "test.gif")
>>> i2 = bob.io.base.load("test.gif")
>>> print i2
array([[[ 16, 248, 248, 248],
        [248,   0, 248, 248],
        [248, 248,   0, 248],
        [248, 248, 248,   0],
        [248, 248,   0, 248],
        [248,  48, 248, 248]],

       [[ 16, 248, 248, 248],
        [248,   0, 248, 248],
        [248, 248,   0, 248],
        [248, 248, 248,   0],
        [248, 248,   0, 248],
        [248,  48, 248, 248]],

       [[ 16, 248, 248, 248],
        [248,   0, 248, 248],
        [248, 248,   0, 248],
        [248, 248, 248,   0],
        [248, 248,   0, 248],
        [248,  48, 248, 248]]], dtype=uint8)

@andre.anjos Do you know, why this is happening, i.e., why we quantize GIFs before writing? Other libraries (such as ImageMagick, with which bob/io/image/data/test.gif was created) do not do that.

added 1 commit

• 5ebd7699 - Fixed handling of multi-frame gif (now, the last frame is used); improved Error reporting

Compare with previous version

added 1 commit

• 3302378b - Switched back to reading first image; later images might be incomplete

Compare with previous version

Not really - Laurent implemented this originally. I just moved the code into this new encapsulation.

Hello @mguenther: we'd like to have a Bob release by the end of the month. Could you please have a look into this old issue?

changed milestone to %Bob 2.7.x release

I am a bit helpless here, too. Reading multi-frame .gif files has now been fixed with the code in this PR. However, GIFs are still written in quantized mode. Hence, the test, where the image is written, read back and compared with its original fails.

One solution would be to disable that test, merge this PR afterwards, and open a new issue with the quantized writing of GIF images.

assigned to @mguenther

added C++ help wanted labels

removed assignee

Hi @mguenther I will remove this from the Bob 2.7.0 milestone then since we are going for an early release.

removed milestone

I mean, I can disable the test (which is not working as noted above), merge this, and open another bug, if you want. But I have no time to solve the writing issue right now.

No. I would rather this to be fixed in the next release.

I have already tagged it too: https://gitlab.idiap.ch/bob/bob.io.image/tags/v2.2.2

OK, as you wish.

why don't we not quantize the bits before writing?

added 11 commits

• 3302378b...d98c3071 - 6 commits from branch master
• f6258afb - Implemented failing test case
• 65833799 - Reading all records from the image; use only the first image inside the GIF
• 819d52ac - Fixed handling of multi-frame gif (now, the last frame is used); improved Error reporting
• 0f4224ac - Switched back to reading first image; later images might be incomplete
• 22614ce5 - Merge branch '26-gif-loading-seems-to-be-completely-broken' of https://gitlab.id…

Compare with previous version