Problem saving GIF

11 views
Skip to first unread message

John Girvin

unread,
Dec 16, 2020, 6:07:37 AM12/16/20
to GrafX2
Saving in GIF format seems to save in the current window size instead of the defined image size. This includes cropping any part of the image that is not visible in the window.

Tested with:
macOS Big Sur 11.1 Intel
Grafx2.app-x86_64-sdl2-2.6.2492.zip
Grafx2.app-x86_64-sdl2-2.7.2978.zip
Self-compiled x86_64-sdl2-2.8wip3058

Does not seem to affect saving in PNG format.

This seems to be a problem with Big Sur. The issue doesn't occurr with the same binaries running on macOS Mojave. I don't have a Catalina machine to test on.

miniupnp

unread,
Dec 17, 2020, 9:08:29 AM12/17/20
to gra...@googlegroups.com, John Girvin
In the GIF format there is both a notion of logical screen size and picture size.
What are you using to display the resulting pictures ?

Please open a ticket on http://pulkomandy.tk/projects/GrafX2/query

regards,

Thomas
--

---
You received this message because you are subscribed to the Google Groups "GrafX2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grafx2+un...@googlegroups.com.
To view this discussion on the web visit https://groups.google.com/d/msgid/grafx2/4d998041-e584-41fc-a7aa-a7b0e21d8967n%40googlegroups.com.

John Girvin

unread,
Dec 17, 2020, 9:29:42 AM12/17/20
to GrafX2
Loading "BG27.gif" in to Grafx2 and immediately saving it as "BG27a.gif".

ImageMagick returns the following:
$ identify BG27*             
BG27.gif GIF 896x256 896x256+0+0 8-bit sRGB 256c 4217B 0.000u 0:00.000
BG27a.gif GIF 896x256 480x281+0+0 8-bit sRGB 256c 4074B 0.000u 0:00.000

Python PIL gives:
BG27: <PIL.GifImagePlugin.GifImageFile image mode=P size=896x256 at 0x1081DB070>
BG27a: <PIL.GifImagePlugin.GifImageFile image mode=P size=896x281 at 0x1062DDCA0>

"BG27a" is the newly saved one.

Loading BG27a back into Grafx2 or Acorn (a macOS paint app) results in an image cropped to 480x281.

480x281 was the window or fullscreen resolution of Grafx2.

miniupnp

unread,
Dec 18, 2020, 6:16:50 AM12/18/20
to John Girvin, gra...@googlegroups.com
Edit your gfx2.ini and make sure Save_screen_size_in_GIF = no 
This feature is probably buggy :(


  ; Save the screen dimensions in GIF | Sauver les dimensions de l'écran dans
  ; files. If you want to read these  | les fichiers GIF. Si vous voulez lire
  ; files with Photoshop or Alchemy,  | ces fichiers avec Photoshop ou Alchemy,
  ; and maybe some other programs, you| et peut-être d'autres programmes, vous
  ; must set this option to 'no'.     | devez mettre cette option à 'no'.
  Save_screen_size_in_GIF = no    ; (default 'no')

John Girvin

unread,
Dec 18, 2020, 6:35:13 AM12/18/20
to GrafX2
I actually found this setting after looking at the GIF saving source code :)
Save_screen_size_in_GIF was YES for some reason (after a fresh install on a new laptop), and setting it to NO in the UI resolved the problems.

So I think you are correct that Save_screen_size_in_GIF=YES is buggy.

Thanks for taking a look.

Adrien Destugues

unread,
Dec 18, 2020, 6:38:12 AM12/18/20
to gra...@googlegroups.com
18 décembre 2020 12:34 "John Girvin" <john....@sportsfusion.co.uk> a écrit:

> I actually found this setting after looking at the GIF saving source code :)
>
> Save_screen_size_in_GIF was YES for some reason (after a fresh install on a new laptop), and
> setting it to NO in the UI resolved the problems.
>
> So I think you are correct that Save_screen_size_in_GIF=YES is buggy.

The comment in the ini file says that this is not compatible with other tools, so I think it's the expected behavior at least for the person who wrote the code. I think the idea is to save the screenmode there to restore it when the file is loaded. It made sense in the DOS version but probably not anymore (since we separately save the pixel scalers for "wide" and "tall" modes now).

--
Adrien.

Yves Rizoud

unread,
Dec 18, 2020, 8:41:08 AM12/18/20
to grafx2
I worked on these functions, and never realized this part was wrong from the beginning, sorry about that.
From the spec of GIF format, in Logical Screen Descriptor (block), the word "screen" is misleading : This size has nothing to do with the display in the physical world, and not even the pixel ratio.
These dimensions set the total image space (a canvas) and each frame/layer (Image Descriptor) modifiy a specific rectangular block.

IMO, we should really deprecate this option.

Note, in the Grafx2 load code you can see lots of stuff that tries to find a suitable "screen" size. This is mostly a leftover of a time when the program would mostly be used to view/edit fullscreen images, and switch to the same resolution for a more WYSIWYG experience.
A large part is meaningless and disabled anyway if you choose option "Auto set resolution : NO", and to be honest, everybody should keep this setting.
What is preserved is an attempt to switch to the intended pixel ratio when it's far from 1:1.


Yves



--

---
You received this message because you are subscribed to the Google Groups "GrafX2" group.
To unsubscribe from this group and stop receiving emails from it, send an email to grafx2+un...@googlegroups.com.

miniupnp

unread,
Dec 20, 2020, 11:54:34 AM12/20/20
to gra...@googlegroups.com, Yves Rizoud
It is legal to have a GIF "canvas size" bigger than the picture. But the picture must fit into that canvas.

The big is if the image is larger than the screen, then the GIF canvas must be bigger.

I think I fixed it :
https://gitlab.com/miniupnp/grafX2/-/commit/6b6f8790d594c0e870055109c9aef71469c5a934
Reply all
Reply to author
Forward
0 new messages