Skip to content
New issue

Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.

Sign up for GitHub

By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.

Already on GitHub? Sign in to your account

Jump to bottom

Fails to save IFF on Windows GIMP 2.8.20 #4

Open
midwan opened this issue Feb 15, 2017 · 29 comments
Open

Fails to save IFF on Windows GIMP 2.8.20 #4

midwan opened this issue Feb 15, 2017 · 29 comments

Comments

@midwan
Copy link

midwan commented Feb 15, 2017

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

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
Copy link
Owner

unwind commented Feb 19, 2017

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
Copy link
Author

midwan commented Feb 19, 2017

@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
Copy link
Author

midwan commented Feb 19, 2017

@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
Copy link
Author

midwan commented Feb 19, 2017

@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
Copy link
Author

midwan commented Feb 19, 2017 •
edited
Loading

@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
Copy link
Author

midwan commented Feb 19, 2017

@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
Copy link
Owner

unwind commented Feb 20, 2017 via email

@midwan midwan changed the title Fails to save IFF on Windows GIMP 2.8.18 Fails to save IFF on Windows GIMP 2.8.20 Feb 20, 2017
@unwind
Copy link
Owner

unwind commented Feb 20, 2017

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
Copy link
Author

midwan commented Feb 20, 2017

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

@midwan
Copy link
Author

midwan commented Feb 20, 2017

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

@unwind
Copy link
Owner

unwind commented Feb 21, 2017

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
Copy link
Author

midwan commented Feb 21, 2017

@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
Copy link
Owner

unwind commented Feb 21, 2017

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
Copy link
Author

midwan commented Feb 21, 2017

@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
Copy link
Owner

unwind commented Feb 21, 2017

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
Copy link
Author

midwan commented Feb 21, 2017

@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
Copy link
Author

midwan commented Feb 21, 2017

@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:

img_0621-25

GIMP itself can reopen the image without the corruption.

Original image was this:
mangaavatar

@unwind
Copy link
Owner

unwind commented Feb 25, 2017

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
Copy link
Owner

unwind commented Feb 25, 2017

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
Copy link
Owner

unwind commented Feb 25, 2017

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
Copy link
Author

midwan commented Feb 25, 2017

@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
Copy link
Owner

unwind commented Mar 3, 2017

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
Copy link
Author

midwan commented Mar 4, 2017

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

@midwan
Copy link
Author

midwan commented Mar 10, 2017

@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

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

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
Copy link
Owner

unwind commented Mar 14, 2017 via email

@unwind
Copy link
Owner

unwind commented Mar 14, 2017

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
Copy link
Author

midwan commented Mar 14, 2017

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
Copy link
Owner

unwind commented Mar 15, 2017 via email

@unwind
Copy link
Owner

unwind commented Mar 28, 2017

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!).

@unwind unwind closed this as completed Mar 28, 2017
@unwind unwind reopened this Mar 28, 2017
Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment
Assignees
No one assigned
Labels
None yet
Projects
None yet
Milestone
No milestone
Development

No branches or pull requests
2 participants
@unwind @midwan