Our ReVolt Pub

Posted: **14 Jun 2012, 00:40**

A few days ago Urne asked if I've ever though about writing a GIMP plugin to assist in mipmaps creation (to make it short, the .bmp along with the .bmq half-sized textures in Re-Volt).

I had no idea about how it could be done, and at first it rather sounded like a lot of work for a something that was not really an essential feature. But I was curious though... so I started looking a the Gimp documentation.
There's in fact at least 3 ways to add a plugin to Gimp:
- Script-Fu, Python and C

I started looking at Script-Fu, which is based on the Scheme programming language (which I don't know at all). It was not looking very engaging and I read in the meantime that Python or C was recommended for the more advanced users. Hey, I've learnt Python to write the Blender IO plugin for Re-Volt, so it would be stupid not to use Python here as well...

So I checked the Gimp API and started writing my first Gimp plugin... Most of the work was pretty straightforward, but several small glitches were quite a nightmare:
- most of the time if the plugin refuses to load you have no idea why, not a single error message (there's probably a tricky way but I don't know it yet). It can take some time before being able to get the plugin to just register in the menu.
- there's not way to refresh the plugin registration except restarting Gimp, and it's doesn't even seem to be enough. Most of the time I have to quit Gimp, restart it with the plugin deleted, quit again and restart with the plugin... It was a real pain.

Anyway, now it's working.

Preview:

Installation:

Place the file "export_rv_mipmaps.py" into:

Windows XP:
C:\Documents and Settings\<username>\.gimp-2.6\plug-ins
Windows Vista/7:
C:\Users\<username>\.gimp-2.6\plug-ins
Linux:
$HOME/.gimp-2.x/plug-in

Launch the Gimp. If the plugin is properly installed an entry "Export RV mipmaps..." should appear in the "File" Menu.

The plugin was tested with GIMP 2.8.
Ensure Python support was enabled during the Gimp installation...

Usage:

Open an image file.
Select File\Export RV mipmaps...
Chose the folder to export mipmap to, and press Ok.

Notes:

I've added .png and .jpg support as well, though for now only .bmp is actuall useful.
The default is to create 2 levels of mipmap (ie. .bmp and .bmq) but this can be increased. I have not checked the v1.2 source but I'm pretty sure we've enabled more than 2 mipmap levels support. WolfR4 also allows to patch the v1207 exe to support more mipmaps.
The plugin uses the name of the current image file for the mipmap files as well (it implies it won't work if the current image has not been saved yet).
Only the part of the image name before the first dot "." is used for the mipmaps name. So you can work on eg. a file named "nhooda.version1.xcf" and it will export to "nhooda.bmp".
The image is resized before merging the layers. It should preserve the sharpness on the edges of a layer when this layer has been cropped to be smaller than the whole image.

Download

The file can be downloaded from my website:
.zip]export_rv_mipmaps.[2012-06-13].zip

FYI I don't think I'll use Kompozer anymore so I'm currently unable to quickly update my website. Well, maybe I'll finally switch to manual html editing,

then I'll add a dedicated webpage...

Posted: **14 Jun 2012, 14:29**

Hey Jigebren,

I have downloaded the plug-in and placed the *.py file inside:
$HOME/.gimp-2.8/plug-ins/

However, the plug-in does not appear in the File menu and I am not sure why. I checked my preferences and plug-ins should be loaded from the folder above. Also tried running GIMP from console but no interesting output it seems.

Any suggestions?

Posted: **14 Jun 2012, 18:27**

Hmm, you see what I mean about the lack of straightforward error message...

I don't have the solution, but I do have several suggestions though:

Do the warning messages about libwebkitgtk in the console also appear when the plugin is not installed?
In the Gimp 2.8 Windows installer there's a checkbox to install Python script support, but I guess than on your Linux distribution it should work out of the box as Python is likely already installed, with all the needed modules (PyCairo, PyGObject and PyGTK)... right?
You can try to install the demo-plugin-GUI from here and see if this one works (should appear in Filters>Demo GUI widgets...)
Most important: you have to set the execute bit for the python script, as I've read on this page.
Code: Select all
```
&#036; sudo chmod +x /usr/lib/gimp/2.0/plug-ins/export_rv_mipmaps.py
```

Posted: **14 Jun 2012, 21:02**

It does work in Windows though, I see the option as the last entry in File menu (even below Quit).

@Urne: Not sure if it makes any difference, but you could also try placing the .py file inside lib/gimp/2.0/plug-ins in your GIMP installation folder.

Posted: **14 Jun 2012, 21:34**

I did a few tests and found out that the errors in the terminal is not related to the plug-in. I also checked that all libraries was installed and they was (python, pygtk, python2-cairo & python2-gobject2). I had forgotten to give the python script execute permissions though - when it doesn't have that permission it won't show up in the File Context menu.

So thanks for the tip jigebren! Problem solved - will test your plug-in out later today.

Posted: **14 Jun 2012, 23:12**

Works flawless with Gimp 2.8 for Windows

Posted: **15 Jun 2012, 00:18**

The plug-in is excellent, thank you very much, Jig!

Is 32-bit bitmaps supported? The reason I am asking is because the exporter doesn't seem to save transparent nor semi-transparent pixels. Instead transparent pixels are rendered pureblack and semi-transparent pixels fully opaque which is a bit of a shame now that Re-Volt 1.2 does 32-bit bitmaps, isn't it?

I have tested exporting 2 levels of mipmaps and 3 levels of mipmaps and both work fine. However, I have a suggestion: To keep backwards compatibility, perhaps the exporter could make *.bmp the standard format for 256x256 bitmaps, and then give other bitmaps an extension accordingly? This might work out as an "option" which can be toggled on or off. Just my thoughts.

Out of curiosity what filter do you use to re-size the picture with?

Posted: **15 Jun 2012, 04:04**

Thanks guys for the feedback.

>> Is 32-bit bitmaps supported?
I just tried and it worked for me... I get a 32bit BMP file with the proper alpha channel.
For info, with the API call to save the BMP (file-bmp-save), the depth is not a parameter so I guess it's automatically chosen according to the image (hmm, in fact it seems to always use 32 bits).
Well, maybe it behaves differently on Linux and Windows. I suggest you send/email me your source and result image files so that I can try here.

>> To keep backwards compatibility, perhaps the exporter could make *.bmp the standard format for 256x256 bitmaps
In fact I think I could let the user enter the image extension (of the greatest mipmap) manually, and detect for example "bmo" as "bmp" format. It won't be automatic, but it should be rather flexible.

>> what filter do you use to re-size the picture with?
The default interpolation method, which is set under "Preference/Tool Options/Scaling" (should be "Cubic" by default).

Posted: **15 Jun 2012, 16:26**

Works flawless with Linux Gimp 2.8

, after with chmod u+x ~/.gimp-2.?/plug-ins/export_rv_mipmaps.py

Posted: **15 Jun 2012, 18:38**

Re: 32-bit bitmaps
Tried exporting to 32-bit *.bmp in Gimp 2.8 again and I actually get the same results. Since Jackieben uses the same Linux distribution as me, he might be able to help me though. Anyway, I don't think this is the fault of your plug-in.

Jigebren wrote:In fact I think I could let the user enter the image extension (of the greatest mipmap) manually, and detect for example "bmo" as "bmp" format.

sounds good to me.

Thanks for the info about the re-size filter too. Will return once I have some news on my 32-bit issues.

EDIT: here is a zip file with the files I am testing:
http://rvzt.net/Temp/take%202.zip

Posted: **15 Jun 2012, 19:01**

I thought plain black means transparent in revolt?

Posted: **15 Jun 2012, 19:06**

@Jackie, yes that's the case on 16-bit and 24-bit bitmaps since they don't have an alpha channel. 32-bit bitmaps however have an alpha channel; each pixels consists of a red, green, blue and an alpha value there. This gives the possibility of having semi-transparent pixels and fully transparent pixels and Re-Volt supports this fully.

I have updated my previous post with a link to the files I am testing, as well as some results.

EDIT: I just tried exporting a 32-bit bitmap in the RGBX format and now the fully transparent pixels are rendered cyan. Sounds a bit like a bug in a library or in Gimp to me.

EDIT2: This problem seems to be related to GIMPs Windows Bitmap image importer. The bitmaps work fine in Re-Volt. This bug report explains the issue in details. I have talked to a few on #gimp in IRC and they say the issue most likely is in:
http://git.gnome.org/browse/gimp/log/pl ... mp-write.c.

Posted: **15 Jun 2012, 19:48**

Thanks for the lesson Urne

Posted: **15 Jun 2012, 20:35**

Good investigation Urne. In fact Gimp on Windows doesn't properly read the 32bits BMP either, but I was checking with XnView, which reads both my images and yours properly. Now, it would be nice to know whether the issue is in the Gimp BMP reading or writing...

For info I have totally rewritten the plugin interface, it will now look more like a regular "Save File" window, with an extra spinner to set the number of mipmaps. It was in fact my initial plan, but I was not able to do it at first try... I guess I was a bit too tired.

Expect another release soon, probably tonight...

BTW, I just wonder for the doc about Linux, which line should I suggest:

Code: Select all

&#036; sudo chmod +x /usr/lib/gimp/2.0/plug-ins/export_rv_mipmaps.py

Code: Select all

chmod u+x ~/.gimp-2.?/plug-ins/export_rv_mipmaps.py

Posted: **15 Jun 2012, 21:21**

Jigebren wrote:Now, it would be nice to know whether the issue is in the Gimp BMP reading or writing...

As far as I understand, the issue only occur when Gimp writes color space information to the bitmap file. You can turn this off under the Compatibility tab when exporting to BMP.

I just tested and Gimp reads 32-bit bitmaps without color space information just fine. When the 32-bit bitmaps contain color space information, however, the issues appear. Re-Volt loads both type of bitmaps just fine.

I am currently cloning the gimp source code using git, since the programmers on #gimp encouraged me to take a look at it. Having no programming experience, we'll see where I get with that I guess.

Jigebren wrote:For info I have totally rewritten the plugin interface, it will now look more like a regular "Save File" window, with an extra spinner to set the number of mipmaps. It was in fact my initial plan, but I was not able to do it at first try... I guess I was a bit too tired.

Nice! Also, please make "Save" or "OK" the active button, so one can simply press Enter on his keyboard if no settings need change upon exporting. I have assigned your plug-in to Ctrl+Alt+E (similar to Export As which is Ctrl+Shift+E), so if it would be very useful.

As to which line to suggest I would say the one where you only add execute permission to the users (chmod u+x):

Code: Select all

chmod u+x ~/.gimp-2.?/plug-ins/export_rv_mipmaps.py

Posted: **16 Jun 2012, 04:02**

urnemanden @ Jun 15 2012, 04:51 PM wrote:I am currently cloning the gimp source code using git, since the programmers on #gimp encouraged me to take a look at it. Having no programming experience, we'll see where I get with that I guess.

I have had unexpected extra free hours in the evening, so I have had a look at this too (directly on the online GNOME GIT source code repository), and I think I've found a few glitches about this issue (though I'm not sure it'll fix the whole issue). So I joined bugzilla.gnome and reported them here.

Unfortunately the "do not write color space information" option doesn't seem to be remembered when saving a BMP from a plugin, so I'm afraid there's currently no way to export BMP with alpha layer from the plugin, which mean we'll have to wait until this is actually fixed and available in a new Gimp release... And it'll probably take long.

Maybe release 2.7 doesn't have this bug, but I don't really feel like trying, and I don't even know if this plugin can be used in previous Gimp releases.

Anyway, I think I just have a few points left to finish before I can publish a new release.
EDIT: well, the new release is finally ready but it's just too late to also update the virtual readme tonight...

Posted: **16 Jun 2012, 04:33**

jigebren @ Jun 15 2012, 11:32 PM wrote: Maybe release 2.7 doesn't have this bug, but I don't really feel like trying, and I don't even know if this plugin can be used in previous Gimp releases.

your plug-ins don't work with gimp 2.6 ...

Posted: **16 Jun 2012, 04:34**

Jigebren wrote:I have had unexpected extra free hours in the evening, so I have had a look at this too (directly on the online GNOME GIT source code repository), and I think I've found a few glitches about this issue (though I'm not sure it'll fix the whole issue). So I joined bugzilla.gnome and reported them here.

Thanks a bunch for looking into this Jigebren! I was told that since no one really uses 32-bit bitmaps it was unlikely that someone else would look at it anyway, so we might be on our own here unfortunately. We'll see..

Jigebren wrote:Unfortunately the "do not write color space information" option doesn't seem to be remembered when saving a BMP from a plugin, so I'm afraid there's currently no way to export BMP with alpha layer from the plugin, which mean we'll have to wait until this is actually fixed and available in a new Gimp release... And it'll probably take long.

No need to wait for it to be available in a new Gimp release. The BMP file importer/exporter works as a plug-in for gimp and can as such be compiled without re-compiling the Gimp itself. Once a fix has been released we can simply bundle the fixed BMP exporter/importer together with your plug-in. If you are curious, the importer is placed here (at least on my system):

Code: Select all

/Gimp2.9/lib/gimp/2.0/plug-ins/file-bmp

Of course, we would have to create executables for both Windows and Linux if we are to keep the plug-in cross-platform then and that could become a bit of a hassle... i believe it's better than nothing though.

Posted: **17 Jun 2012, 02:04**

The release was a bit delayed because I spent quite some time today on the Gimp issue with 32 bit BMP files, but here it is now.

First of all, a little explanation:
The first version of the plugin was using the automatic interface provided by gimpfu: it's a very convenient way to ask user for some parameters when running the plugin, but it's quite restricted... For example it was not possible to suggest a default directory based on the currently opened image.
In this new version I'm managing my own call to GTK, which means I now have the control of the interface.

So the internal of the plugin is the same but the interface has completely changed. Here's a summary of the differences:

You're now asked for a file instead of a directory. That way:
- the name of the exported mipmap file can be changed (it still automatically suggested from the current image name).
- the export folder is set by default to the same folder than the current image file (instead of the default User's folder) at first call.
- then last letter of the extension can be modified (for example to export a 512x512 texture with extension .BMO so that the .BMP mipmap will still be used for 256x256 (backward compatibility with legacy Re-Volt)).
the exported filename is remembered for each image during a Gimp session.
the image format is automatically set according to the extension. Supported formats: are still BMP, PNG and JPG.

The new release can be downloaded here:
.zip]export_rv_mipmaps.[2012.06.16].zip

EDIT:
Oh, and about the BMP issue with alpha channel:
It's likely ok to export 32 bit BMP through this plugin as the main issue with Gimp is when importing the BMP. So they won't look transparent in Gimp but an other software should display it properly (like XnView, and hopefully Re-Volt v1.2).

@Urne: I don't know if you can easily compile GDK as well (as you did for Gimp I guess)... In that case maybe you can try the io-bmp.c fix I suggested.

offtopic1: ImageShack doesn't seem to provide thumbnail code anymore.

I have to remember to add the ".th" to get it (or maybe it's because the image is not big enough....)
offtopic2: Nested list (ie. list inside a list) works properly in the Post preview but it'll be broken in the post. Weird...

Posted: **17 Jun 2012, 04:23**

Nice, Jigebren! Just tested it with 2 and 3 levels of mipmaps and it works very well.

Jigebren wrote:@Urne: I don't know if you can easily compile GDK as well (as you did for Gimp I guess)... In that case maybe you can try the io-bmp.c fix I suggested.

I can easily compile GDK, I have already done so with your fix actually. However, I have no idea to get Gimp to "use" GDK. So far I see no change when simply using the same prefix (that is, the same folder where it is to be installed).

Talked to some on #gimp and the fact that the bmp is imported through gdk-pixbuf appears to be a last resort fix. They think writing new code in bmp-read.c would be a better solution in this case.

PS: Only the filename is marked automatically in the save dialogue. Can you make the file extension selected too? In case that the defaults doesn't work out, both are supposed to be changed to ones liking anyway so I think this would make sense.

Posted: **17 Jun 2012, 05:00**

>> I can easily compile GDK, [.. ]However, I have no idea to get Gimp to "use" GDK.
Thanks for the test. On windows I guess we would have to overwrite the dll "libgdk_pixbuf-2.0-0.dll", so maybe it it's something similar on Linux, you would have to overwrite the library file.

>> Only the filename is marked automatically in the save dialogue. Can you make the file extension selected too?
No, this seems to be the default behavior of gtk.FileChooser.set_current_name.

And yes, I'm already releasing an update.

There's a few improvements:

mipmaps folder and filename are remembered separately to have a smarter filepath suggestion: source images in a same folder will be suggested the same folder for mipmap, source images will same filename will be suggested the same mipmap filename. (not sure the explanation is very clear, but it should be way more convenient when working on a track)
error message if an unsupported extension is chosen.
"Untitled.bmp" suggested for image with no filename.

If there's no major issue this should be the "definitive" release.

Download:
.zip]export_rv_mipmaps.[2012.06.17].zip

Posted: **17 Jun 2012, 18:10**

Jig wrote:Thanks for the test. On windows I guess we would have to overwrite the dll "libgdk_pixbuf-2.0-0.dll", so maybe it it's something similar on Linux, you would have to overwrite the library file.

Got it working! I can confirm that the issues Gimp have with reading 32-bit RGBA BMP files are fixed by the fix you have suggested. I was told that it would be clever to open a new bug report aimed towards gdk-pixbuf and attach the fix as a patch.

Jig wrote: And yes, I'm already releasing an update.

Will get to use this plug-in in practice once I start on the track for the track competition. I'm sure it will come in handy!

Jig wrote:If there's no major issue this should be the "definitive" release

I have one minor suggestion:

Is it possible for you to control the function of pressing "Tab"? I usually navigate menus by keyboard using Tab to get to the next element that needs interaction. Currently the filename is auto-selected for me to change. It would be nice if upon pressing "Tab", the mipmaps number could be activated, and thereafter the Save button.

EDIT: 32-bit RGBX BMP files still isn't read properly even after the fix but I assume they aren't really of any interest for us since Re-Volt doesn't load them either. Have created a bug report on it however: https://bugzilla.gnome.org/show_bug.cgi?id=678250

EDIT 2: New bug report here with your patch included: https://bugzilla.gnome.org/show_bug.cgi?id=678248

EDIT 3: Jigebren, I didn't create a patch for bmp-write.c - are the changes you made here still necessary?

EDIT 4: decided to create another bug report for the glitch in bmp-write.c. Now all bugs found in the first bug report thread has been divided into 3 different bug reports. I did this to keep some sort of separation between them as they only are associated indirectly. Here is a link to the third bug report:
https://bugzilla.gnome.org/show_bug.cgi?id=678252

Posted: **18 Jun 2012, 02:14**

>> Is it possible for you to control the function of pressing "Tab"?
I think it is, though probably not easy at all in that case, but it would not be logical to modify it, as we rather expect the tab key to follow the interface layout.
Just for fun I'll try to see if I can directly modify the layout to something more convenient.

A few thoughts about shortcuts:

In a previous post you (Urne) said you assigned a keyboard shortcut to the plugin. Well, at least on Windows it can be launched just by pressing [Alt+F] then [M]. I agree it's a bit longer then one single key combination but it works out of the box. I don't know though if Linux has the same shortcut support through Alt+(underlined letter).

>> It would be nice if upon pressing "Tab", the mipmaps number could be activated, and thereafter the Save button.
1. The number of mipmaps is shared for all images during a Gimp session, and once set I guess this value has not reason to be changed again, hasn't it? 2. There no real need to use the [Tab] key to reach the "Ok" button as you can simply press the [Enter] key, no matter where the focus is. 3. If you really want to reach the mipmaps number with shortcut you can still hold the [Shift] key and press [Tab] 3 times...

offtopic with Urne:
- I have not checked yet about 32-bit RGBX BMP but I'll try to have a look.
- I agree it's clearer to have separate bug reports. BTW I see no reaction except us for now, does it mean we're really on our own about this, or do you think we have to wait until some Gimp devs have time to focus on this?
- About the bmp-write.c, I'm not sure the whole code is actually consistent, but I'm quite sure it's better with my modification than without. If you check the BITMAPV5HEADER structure you can see that there's no reason to ever skip the 4 mask members (just before the "bV5CSType" member). So yes, the change still look necessary to me.
- BTW, don't you know any Gimp dev ready to compile a fixed "libgdk_pixbuf-2.0-0.dll" for Windows?

Posted: **19 Jun 2012, 21:30**

>> In a previous post you (Urne) said you assigned a keyboard shortcut to the plugin. [..] I don't know though if Linux has the same shortcut support through Alt+(underlined letter).
Linux does have that, but I personally find it more convenient to press one keyboard combination than 3 buttons in chronological order.

>> The number of mipmaps is shared for all images during a Gimp session, and once set I guess this value has not reason to be changed again, hasn't it?
Hmm, you are actually right about that. Nevermind then.

>> There no real need to use the [Tab] key to reach the "Ok" button as you can simply press the [Enter] key, no matter where the focus is.
Unless I press tab and select a button which reacts on Enter itself.

>> 3. If you really want to reach the mipmaps number with shortcut you can still hold the [Shift] key and press [Tab] 3 times...
Right, got it.

>> - I agree it's clearer to have separate bug reports. BTW I see no reaction except us for now, does it mean we're really on our own about this, or do you think we have to wait until some Gimp devs have time to focus on this?
Hmm, I am not sure. Those I spoke to on IRC said we probably would be on our own on this because 32-bit bitmaps isn't used very much anymore. Of course, for every comment we make on those bug reports, 30 e-mails are sent to other e-mail adresses so someone might get interested at some point.

>> About the bmp-write.c, I'm not sure the whole code is actually consistent, but I'm quite sure it's better with my modification than without.
I have updated the bug reports with attachments of the resulting bmp's when exporting a bitmap with the changes you have suggested in bmp-write.c. That's the case even when they loaded in Re-Volt, which wasn't the case with earlier 32-bit bitmaps exported from Gimp.

>> - BTW, don't you know any Gimp dev ready to compile a fixed "libgdk_pixbuf-2.0-0.dll" for Windows?
Seems to require cygwin - I'll have a look at it - don't know any Gimp developers but will ask around in #gimp.

Posted: **20 Jun 2012, 01:08**

little bug on the plug-in (who is not realy one)

It's a "cubic" interpolation issue ... using "none" would solve this

Posted: **20 Jun 2012, 03:42**

Urne wrote:Currently the filename is auto-selected for me to change. It would be nice if upon pressing "Tab", the mipmaps number could be activated

Just a note about the Tab key behavior in the GDK file selector widget: If you ever try to press Tab right when the file name is pre-selected, it will likely modify the name entry instead of jumping to the next widget.

In fact there's a feature called tab completion or something like that, which appears to be activated by the tab key. If for example the filename "my_image" is preselected and there's a file named "my_image_01.bmp" in the current folder, by pressing [Tab] "my_image" will be replaced by "my_image_01.bmp".
I haven't find any clear doc about this feature so far, and it doesn't always sound very consistent / handy as it may eg. insert a name with an extension even if the extension was already written (but not pre-selected), and it can prevent IMO a proper use of the Tab navigation shortcut.

Urne wrote:That's the case even when they loaded in Re-Volt, which wasn't the case with earlier 32-bit bitmaps exported from Gimp.

Hmm, I'm not sure I get it. What wasn't the case, but is now?

@SebR
Well, that's not a bug neither an issue.

(or I overlooked something...)
The interpolation method is the default Gimp one, which can be set under "Preference/Tool Options/Scaling" (and is "Cubic" by default).

BTW even if you do want to use a non-antialiased image, I'm quite sure that by design using "None" to create mipmaps doesn't really make sense (especially for the lowest mipmaps). Some details like eg. a thin line could suddenly disappear, while AFAIK mipmaps rather intends to "make things look smoother".

Posted: **20 Jul 2012, 06:15**

This plugin now has its own page on my website. To download the last version or to read the updated documentation, go to:
http://jigebren.free.fr/games/pc/re-volt/gimp/

Posted: **22 Jul 2012, 16:36**

Great to see, Jigebren! There is some small spelling mistakes somewhere on that page though, try search for "mipamps" and "mimpap" and you should find them. Anyway, thanks for creating this plug-in - will for sure come in handy.

Posted: **30 Jul 2015, 10:29**

I am having issues in both Windows and Linux with 32-bit bitmap alpha. In Gimp 2.6 this use to be no problem because it would read and write as the developers intended, but 2.8 now renders transparency as pure black and I can't help to ask if somebody has a solution for this that doesn't involve compiling or finding a PPA for 2.6.

I really, really, really don't want to give up 2.8's single-window mode just because it's a damn fine feature, so knowing how to import and export bitmaps with alpha would be pretty awesome.

Our ReVolt Pub

Gimp Plugin To Export Mipmaps