GNOME Bugzilla – Bug 605000
Add 32bit Sun Rasterfile format (.im32) as a exportable file format
Last modified: 2018-05-24 12:43:29 UTC
GIMP can load 32bit ras file (.im32), but not save in this format. It is always set back to .im24. It would be very helpful if .im32 would be included as a saveable file format. Though it is not specified in the ras documents, the fourth byte which would normally be zero should be used for transparency(!). As GIMP is the only program supporting Rasterfiles, i know of, there shouldn't be any conflicts.
This should be fairly trivial for RGBA images, not sure about GRAYA and INDEXEDA images. The relevant sourcecode file is plug-ins/common/file-sunras.c and apparently already did some preparations for the bpp=4 case, search for "SUNRAS_32". The other thing to fix is the registration of the plugin, so that gimp knows that the plugin can deal with RGBA (and not just RGB) images. Setting the gnome-love keyword, this is a task for people who want to enter gimp development, please feel free to ask for support in #gimp (gimpnet).
Please note that - from reading the code - loading these files does not load the alpha channel. I am not sure if we should try to "abuse" the fourth byte. Why is sunras an interesting format anyway? :-)
We can only do this if it is clearly specified in the file format documentation. Since it isn't, we should do the correct thing and do not save an alpha channel into those files. 32bit is just 24bit RGB padded to 32bit. That is rather common. So we can of course keep this request for saving .im32 files, assuming that this format is specified, but we should not abuse the padding bits to store any information. Setting the bug report to NEEDINFO until a pointer to the docs has been added.
Well, I would appreciate if saving to .im32 would be enabled at all. But what would be the problem in making an option to save the alpha channel (for rgb[a]) in the the padding byte? I guess not using the padding byte for anything is the reason it is not available for saving. It would be useless, except in may be faster loading of 4bytes (lodsd) at a time compared to 3bytes (3xlodsb). The advantage of Sun Rasterfiles is their plain stupid file structure combined with available RLE. For game development an ideal format (if transparency would be added). All the Info I can provide is here: http://www.fileformat.info/format/sunraster/egff.htm
If the problem is that transparency is not mentioned in the original sunras defintion just offer a .im32t file format being .im32 with transparency in the fourth padding byte for rgb(a) images.
If you need to derive your own proprietary file format from the Sun Rasterfile format, then please feel free to do that. You can easily extend GIMP to support your format. We will not add features that are not clearly specified in the file format specifications. That only leads to trouble and confusion. So this enhancement request is about adding 32bit ras file (.im32) with 24bit RGB data and 8bit padding (zero).
[Quote]This should be fairly trivial for RGBA images, not sure about GRAYA and INDEXEDA images.[/Quote] im24 and im32 are RGB-Only as far as i know. If this reduces just to be able to save in .im32 format thats fine with me. I'll just write a standalone tool to convert it as i want. Though i don't see the point where "trouble and confusion" comes when saving the alpha channel is as optional as using RLE encoding. I have one more question: On what standard is the loading and saving of rasterfile's based up to now? If you could point me to them i could check them against my web sources, so i won't implement any non standard stuff in my projects. Thanks.
Just to explain where the trouble might come from. If we implement saving of the alpha channel, then people expect that they can also load the alpha channel. So we will have to add support for loading as well. And it would have to be implemented optionally, so we would have to add a dialog for loading to let the user decide how the file should be interpreted. That's where the confusion would come in. This is not a decision a user should have to make. By sticking to the format specification, we avoid such dis-ambiguities. I can't tell you which spec was used to implement the plug-in in the first place. Might help to check the source for comments and/or browse the file history.
May be i understand something wrong here, so pease correct me if this is the case. Assuming saving with alpha channel is implemented for rasterfiles, as i suggested optionally. Then first this would only apply to im32 format with the free padding byte. If you want to load an im32 file, gimp can figure out if alpha channel is existing, by checking if the padding bytes are zero or not. Or one could even use, in the Type field, 0xFFFF (experimental) instead of 0x0003 (RGB) when saving, which is mentioned as a valid rasterfile type, menaing that the image body can contain non standard parts. So wether gimp tests the padding byte when loading or experimental type is used when saving the user doesn't have to act when loading, or am i wrong. If you just do not want to implement just say so.
Hi. I think we have been pretty clear already. We are not going to use the fourth byte for alpha information since, at least as far as I can tell, the file format specification does not support that. That this bug report is still open should be interpreted as "we will accept patches that implement saving in the specified .im32 format".
-- GitLab Migration Automatic Message -- This bug has been migrated to GNOME's GitLab instance and has been closed from further activity. You can subscribe and participate further through the new bug through this link to our GitLab instance: https://gitlab.gnome.org/GNOME/gimp/issues/318.