Fails to save IFF on Windows GIMP 2.8.20

[midwan]

I get an error when trying to Save an image as IFF:

This happens after I select "Export As", select a filename and get the "Save as IFF" window to show up (which also pops up the black shell window in the background, still). Once I click on OK, using the default settings, this message comes up and no file is saved.

This was tested on GIMP 2.8.18

[unwind]

Hi!

I just tried it in Linux (my operating system of choice) and it does work there.

So, it seems we need more information about what fails. There aren't many clues in the error, unfortunately. No idea how to make that better, at the moment.

Sorry for the inconvenience!

[midwan]

@unwind Agreed, it is a bit strange since nothing that should affect that has changed recently. I suspect that there's something wrong in my installation, so I'll try it on a blank VM and see.

[midwan]

@unwind Curious about one thing: how do you debug the plugin? Do you have an environment where you can run it, set breakpoints and monitor what's going on?

[midwan]

@unwind Confirmed in a blank VM with Win10, fresh installation of GIMP 2.8.20 and the compiled plugin - save error when saving.

This probably means that my compiled version is problematic, I'll check my dev environment and update everything, then run another set of tests.

[midwan]

@unwind Hmm, unfortunately even with a full update from source on each component (babl, gegl, gimp) and a full recompile/reinstallation of everything, the error remains. I've tested it in both GIMP 2.8.20 and 2.9 (git from master branch), it behaves the same in both.

Strangely, in 2.9 I don't get the empty shell window in the background during the Export As dialog...

I'll try to setup another environment to compile it from... ;)

[midwan]

@unwind It took me a few hours, but I setup an environment with Visual Studio so I can now compile and edit the code from there (using VisualGDB, a commercial add-on).

I had the same problem at first, so I decided to try an alternative and get the specific versions of gegl and gimp that the final "stable" release uses: gegl-0.2 and gimp-2.8 (instead of gegl-0.3 and gimp-2.9). When I got the same results, I tried an older binary of the plugin - still the same.

I uninstalled GIMP completely and cleaned up all relevant folders, re-installed it... the same.

And just when I thought I was going crazy, I found out what the problem was:

• the specific image I was testing with!

I don't really know why, but that specific IFF file refuses to save from Gimp, even though it can be opened. Maybe some of the file's properties (it's a 320x240x6 IFF ILBM)?

I tested another one and it worked fine.

I'm attaching the problematic sample image here, so you can test from your side also: Sony17.zip

[unwind]

Hi!

That's an excellent bug exploration effort, thanks a lot!

And no, I don't have an environment where I can debug the plugin except by adding printf()s and starting Gimp from a terminal.

It's not optimal, but I haven't spent much time debugging it either; I'd be surprised if it's not possible to achieve something better.

Great that you included the image, I'll try to take a look in Linux too. Thanks for all your help.

Regards,

/Emil

On Sun, Feb 19, 2017 at 11:46 PM, Dimitris Panokostas < notifications@github.com> wrote:

@unwind https://github.com/unwind It took me a few hours, but I setup an environment with Visual Studio so I can now compile and edit the code from there (using VisualGDB, a commercial add-on).

I had the same problem at first, so I decided to try an alternative and get the specific versions of gegl and gimp that the final "stable" release uses: gegl-0.2 and gimp-2.8 (instead of gegl-0.3 and gimp-2.9). When I got the same results, I tried an older binary of the plugin - still the same.

I uninstalled GIMP completely and cleaned up all relevant folders, re-installed it... the same.

And just when I thought I was going crazy, I found out what the problem was:

• the specific image I was testing with!

I don't really know why, but that specific IFF file refuses to save from Gimp, even though it can be opened. Maybe some of the file's properties (it's a 320x240x6 IFF ILBM)?

I tested another one and it worked fine.

I'm attaching the problematic sample image here, so you can test from your side also: Sony17.zip https://github.com/unwind/gimpilbm/files/786273/Sony17.zip

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/unwind/gimpilbm/issues/4#issuecomment-280956284, or mute the thread https://github.com/notifications/unsubscribe-auth/AAt7L1Lge3TK8vO6gH13mz_0dL4ftJe_ks5reMZbgaJpZM4MBdbq .

[unwind]

When trying to re-export the Sony17.iff image in Linux, I get this on the console:

Unsupported drawable type 2

Looking through the code, type 2 corresponds to GIMP_GRAY_IMAGE, which I assume is grayscale. I'm not sure how to interpret the pixels of a grayscale image in a way compatible with ILBM, but perhaps it's just 1:1 from pixel value to intensity, or something. That still means the resolution is way more than ILBM can handle, of course (max 256 steps vs max 32 steps).

[midwan]

@unwind Let me see if I can find any documentation that might help us on this...

[midwan]

@unwind Have you checked here? http://wiki.amigaos.net/wiki/ILBM_IFF_Interleaved_Bitmap

[unwind]

Nope, but not sure what you mean. I guess I'm thinking of ILBMs as being compatible with actual Amiga hardware, and that rules out 8-bit grayscale. I grew up hacking on Amigas, so this is just something I know.

That leaves quantizing down to 32 grayscales (or 64 with half-brite) but image quantization code is not exactly trivial so I'm not so sure I want to go down that path. A better error message would be nice, though. :) Perhaps it's possible to hide ILBM from GIMP for grayscale images altogether, that would simplify things.

[midwan]

@unwind Hm, now I'm not sure what you mean instead. :) This image was created on a real Amiga (years ago) and can be opened there normally.

So if it can be used as-is, shouldn't the problem be how to (re)save it in the same format?

[unwind]

Aha, right. I did think "it's a bit strange that it's an IFF to begin with" while typing the above. :)

Yeah, guess the problem should be that. However I suspect that if we allow GIMP to load this image as grayscale, it will get 8-bit resolution and be much harder to save back out with losing quality.

I'll need to dig more into it to see what's going on, I'm quite vague on the current status of grayscale and indexed modes in GIMP to begin with.

Thanks for pushing. :)

[midwan]

@unwind Was "grayscale" even a separate mode in the Amiga IFF format? I suspect that it was all just palette based and didn't really differ.

Could we have it loaded as Indexed color instead of grayscale? Would that make a difference?

[unwind]

Not in my recollection no but the reference you linked mentions it in the ILBM.XBMI chunk.

Yes, loading as Indexed makes sense, that might make the problem with saving go away. :)

[midwan]

@unwind Did a quick test:

else if(*cmap && !(camg->viewModes & ham))
    {
        isGray = FALSE; //isGrayscale(*cmap, ncols);
        if(isGray)
        {

And re-loaded the image here, then attempted to Save it (Export As) again. It saved it without a problem and it can re-open the saved image correctly also.

One thing I noticed though, that may warrant further investigation: The new file saved by GIMP, could no longer be opened with Directory Opus 12 for Windows. Opus normally opens at least some IFF formats, and it can open the original one correctly.

I tested with different images and they also, when saved as IFF could not be opened from Opus anymore.

In other words, I'd like to test this on a real Amiga and different applications to be sure the output format works correctly. :)

I'll do that tonight at home and get back to you.

[midwan]

@unwind I did a test with my real Amiga, to check if the images GIMP saves are readable. MangaAvatar.zip

I first tried MysticView (an image viewer from Aminet), which failed to open the image. The I tried ImageFX 4.5, which complained about "error in packed format", but opened the image nevertheless, although it's a bit corrupt at the bottom part:

GIMP itself can reopen the image without the corruption.

Original image was this:

[unwind]

Once again, thanks for the epic follow-up and testing efforts.

The grayscale workaround seems sensible. I'll try to look more into it now.

The corruption issue should perhaps be made into a separate issue for better tracking. It seems really strange that one program (on the Amiga) complains about format corruption while another loads it just fine.

No chance the file got damaged when transferring it to the Amiga? Just grasping here ...

[unwind]

By the way, I just saw in the code (and in this version of the standard) one thing that is clearly obvious once you know it:

An IFF-ILBM with no palette (CMAP) chunk can be interpreted as being grayscale.

That makes sense, it seems to occur "in the wild" and it's clearly what the code tries to live up to.

[unwind]

I tried just adding support for grayscale save (the code is oddly prepared for it in some places) and it worked, I got an image that loads.

The identify tool (from Imagemagick) says:

emil@synapse:~/data/workspace/gimpilbm$ identify ~/sony17-test.iff 
ilbmtoppm: input is a 8-plane ILBM
ilbmtoppm: warning - 8 extraneous bytes in BODY chunk
ilbmtoppm: premature EOF in BODY chunk
/home/emil/sony17-test.iff PPM 320x240 320x240+0+0 8-bit sRGB 230KB 0.000u 0:00.000
identify: delegate failed `"ilbmtoppm" "%i" > "%o"' @ error/delegate.c/InvokeDelegate/1310.

I think it's super weird that the BODY chunk has both extraneous bytes, and ends prematurely.

[midwan]

@unwind Thanks for the update.

Regarding the corruption, both applications I tested complained about errors in the file, just one managed to open it though (ImageFX). So it seems there's definitely something there...

If you prefer that as a separate issue, that's fine with me. :)

Regarding the grayscale fix, are those results from ImageMagick after saving the file? I think the original one was a 6-plane ILBM, or am I wrong?

[unwind]

I fixed the extraneous data that appeared, that was due to a silly bug in the BODY chunk writing.

Didn't check if it's my bug, or if it always was there.

That shouldn't help with the corrupted data, but I'd be happy to be proven wrong, so please try it out if you have a chance. Thanks!

[midwan]

Great, I'll test it later today and let you know!

[midwan]

@unwind Finally got a chance to test the latest changes. :)

The problem seems to be solved. I tried loading IFF images from Deluxe Paint IV, some in LowRes 32 colors, others in HAM-6. All opened normally.

Then I saved each one back from Gimp, using the plugin. The indexed palette ones were saved as such again, and the HAM ones I saved as HAM (enabling the checkbox in the plugin Save dialog).

Then I tried loading the saved files again, in GIMP, Directory Opus and Deluxe Paint IV itself. All the indexed palette ones (32 color) were loaded normally everywhere. However, the HAM-6 one was corrupted when loaded.

The original HAM image was this:

After saving it as HAM from Gimp, it opens like this (everywhere you open it, including Gimp itself):

I also tried loading a PNG image, then Export As IFF. That worked also, without problems. The only thing I noticed about this step was that it got saved as a 24-bit IFF. I assume that if I had converted the image to an indexed palette one, it would be saved as such? Nevertheless, DPaint could open it as an IFF-24bit anyway, so we're good.

If we manage to address the HAM saving problem, it would be great! Note: This got saved as HAM-6 from what the applications say. What about HAM-8 support?

[unwind]

Hi!

Sorry for answering so late. Thanks a lot for the detailed follow-up, very nice to hear that progress is being made.

That HAM image did not look so awesome, that's no good. Not sure how easy that's going to be to fix (HAM feels really arcane, today!) but I'll try to have a look when time permits. No idea about HAM-8, that is after my time and I'd have to read up on what it is and when to use it.

Again, thanks a lot for your support.

On Fri, Mar 10, 2017 at 5:00 PM, Dimitris Panokostas < notifications@github.com> wrote:

@unwind https://github.com/unwind Finally got a chance to test the latest changes. :)

The problem seems to be solved. I tried loading IFF images from Deluxe Paint IV, some in LowRes 32 colors, others in HAM-6. All opened normally.

Then I saved each one back from Gimp, using the plugin. The indexed palette ones were saved as such again, and the HAM ones I saved as HAM (enabling the checkbox in the plugin Save dialog).

Then I tried loading the saved files again, in GIMP, Directory Opus and Deluxe Paint IV itself. All the indexed palette ones (32 color) were loaded normally everywhere. However, the HAM-6 one was corrupted when loaded.

The original HAM image was this: [image: image] https://cloud.githubusercontent.com/assets/3877365/23802134/a779ccda-05b2-11e7-84ab-3d9c7ad69bf6.png

After saving it as HAM from Gimp, it opens like this (everywhere you open it, including Gimp itself): [image: image] https://cloud.githubusercontent.com/assets/3877365/23802183/c7ad0bca-05b2-11e7-857c-c6c87739e6f6.png

I also tried loading a PNG image, then Export As IFF. That worked also, without problems. The only thing I noticed about this step was that it got saved as a 24-bit IFF. I assume that if I had converted the image to an indexed palette one, it would be saved as such? Nevertheless, DPaint could open it as an IFF-24bit anyway, so we're good.

If we manage to address the HAM saving problem, it would be great! Note: This got saved as HAM-6 from what the applications say. What about HAM-8 support?

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/unwind/gimpilbm/issues/4#issuecomment-285707345, or mute the thread https://github.com/notifications/unsubscribe-auth/AAt7L0BJGzJ9De2LrraWOg-WroRtHfGXks5rkXOegaJpZM4MBdbq .

[unwind]

Oh, also, can you share that original HAM image in Amiga format? It turns out finding HAM IFF images online isn't super-easy ... Thanks!

[midwan]

Spaceship.zip

@unwind I'm attaching an archive with 3 images:

• One in the original IFF 24-bit format
• The same image as HAM8 (AGA)
• The same image as HAM6 (ECS), this one has reduced width to half but pay no attention to that.. :)

I hope that helps!

[unwind]

Great, that really helps a lot.

Thanks!

/Emil

On Tue, Mar 14, 2017 at 11:11 PM, Dimitris Panokostas < notifications@github.com> wrote:

Spaceship.zip https://github.com/unwind/gimpilbm/files/842890/Spaceship.zip

@unwind https://github.com/unwind I'm attaching an archive with 3 images:

• One in the original IFF 24-bit format
• The same image as HAM8 (AGA)
• The same image as HAM6 (ECS), this one has reduced width to half but pay no attention to that.. :)

I hope that helps!

— You are receiving this because you were mentioned. Reply to this email directly, view it on GitHub https://github.com/unwind/gimpilbm/issues/4#issuecomment-286577425, or mute the thread https://github.com/notifications/unsubscribe-auth/AAt7LyGkuaaIk3sAUwBNGklLlJCRILf6ks5rlxCkgaJpZM4MBdbq .

[unwind]

After a very cursory reading the other night, I think maybe there is no code to write HAM data? It's weird, and I'm really not familiar enough with the code to know for sure. Need to dig more, and perhaps re-implement it (which seems kind of like fun!).