|Printable Version of Topic
Click here to view this topic in its original format
|Our ReVolt Pub > Development, Projects & Tools > Gimp Plugin To Export Mipmaps|
|Posted by: jigebren 13 Jun 2012, 08:10 PM|
| http://z3.invisionfree.com/Our_ReVolt_Pub/index.php?showtopic=1500&view=findpost&p=22000573 Urne asked if I've ever though about writing a http://www.gimp.org/ 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 http://z3.invisionfree.com/Our_ReVolt_Pub/index.php?showtopic=1500&st=0 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.
Place the file "export_rv_mipmaps.py" into:
The plugin was tested with GIMP 2.8.
Ensure Python support was enabled during the Gimp installation...
The file can be downloaded from my website:
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 by: urnemanden 14 Jun 2012, 09:59 AM|
| Hey Jigebren,
I have downloaded the plug-in and placed the *.py file inside:
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 http://pastebin.com/9N3HzUeU it seems.
|Posted by: jigebren 14 Jun 2012, 01:57 PM|
| 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:
|Posted by: Huki 14 Jun 2012, 04:32 PM|
| 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 by: urnemanden 14 Jun 2012, 05:04 PM|
| 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 by: jackieben 14 Jun 2012, 06:42 PM|
|Works flawless with Gimp 2.8 for Windows|
|Posted by: urnemanden 14 Jun 2012, 07:48 PM|
| 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 by: jigebren 14 Jun 2012, 11:34 PM|
| 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 by: jackieben 15 Jun 2012, 11:56 AM|
|Works flawless with Linux Gimp 2.8 , after with chmod u+x ~/.gimp-2.?/plug-ins/export_rv_mipmaps.py|
|Posted by: urnemanden 15 Jun 2012, 02:08 PM|
| 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.
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:
|Posted by: jackieben 15 Jun 2012, 02:31 PM|
|I thought plain black means transparent in revolt?|
|Posted by: urnemanden 15 Jun 2012, 02:36 PM|
| @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 https://bugzilla.gnome.org/show_bug.cgi?id=676219 explains the issue in details. I have talked to a few on #gimp in IRC and they say the issue most likely is in:
|Posted by: jackieben 15 Jun 2012, 03:18 PM|
|Thanks for the lesson Urne|
|Posted by: jigebren 15 Jun 2012, 04:05 PM|
| 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:
|Posted by: urnemanden 15 Jun 2012, 04:51 PM|
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.
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):
|Posted by: jigebren 15 Jun 2012, 11:32 PM|
I have had unexpected extra free hours in the evening, so I have had a look at this too (directly on the online http://git.gnome.org/browse/gimp/tree/plug-ins/file-bmp), 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 https://bugzilla.gnome.org/process_bug.cgi.
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 by: sebr 16 Jun 2012, 12:03 AM|
your plug-ins don't work with gimp 2.6 ...
|Posted by: urnemanden 16 Jun 2012, 12:04 AM|
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..
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):
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 by: jigebren 16 Jun 2012, 09:34 PM|
| 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:
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 by: urnemanden 16 Jun 2012, 11:53 PM|
| Nice, Jigebren! Just tested it with 2 and 3 levels of mipmaps and it works very well.
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 by: jigebren 17 Jun 2012, 12:30 AM|
| >> 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:
|Posted by: urnemanden 17 Jun 2012, 01:40 PM|
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.
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!
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:
|Posted by: jigebren 17 Jun 2012, 09:44 PM|
| >> 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 http://msdn.microsoft.com/en-us/library/windows/desktop/dd183381%28v=vs.85%29.aspx 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 by: urnemanden 19 Jun 2012, 05:00 PM|
| >> 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 by: sebr 19 Jun 2012, 08:38 PM|
| little bug on the plug-in (who is not realy one)
It's a "cubic" interpolation issue ... using "none" would solve this
|Posted by: jigebren 19 Jun 2012, 11:12 PM|
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.
Hmm, I'm not sure I get it. What wasn't the case, but is now?
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 by: jigebren 20 Jul 2012, 01:45 AM|
| This plugin now has its own page on my website. To download the last version or to read the updated documentation, go to:
|Posted by: urnemanden 22 Jul 2012, 12:06 PM|
|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 by: ElectricBee 30 Jul 2015, 05:59 AM|
| 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.