XBM & XPM Datatypes are aros-archive

http://archives.a...type/image


With Multiview v1.8 you cannot save XBM & XPM images

With Multiview v1.7 you can only save XBM images

With Multiview v1.8 you can only save PPM images (Save and Save As)

AMIGASYSTEM

Whether or not you can save images with MultiView 1.7 or MultiView 1.8 depends on the datatypes you have on your system. To say a datatype works with one version but not the other doesn't seem right.

As I suspected XBM and XPM are X Windows datatypes but no source code is provided.

So if you are interested you could install a nice Hex Editor and a code editor with syntax highlighting. For Windows 10 I use HxD Hex Editor. For code editing I use Visual Studio Code or ActiPro Code Writer. You already have the Picture Datatype Creation Package.

Now you just need a good pair of reading glasses to do the online research. Start writing you XBM and XPM datatypes by finding the file format documentation for each file type.

Look at some existing datatypes to see how to write the load and save functions. Look at PNM datatype. It's easier to understand. BMP is a little complicated. Happy coding!

OK thanks for the info, but at the moment it is not important to save the 'XBM' format, all other graphic formats can be saved.

What is important is that AROS recognises the most commonly used graphic formats on the web and has a tool to display them correctly.

Today I have finished all the Def Icons, created the def_XBM, def_XPM, def_PPM, def_TIF_,def_WEBP, def_SVG, AROS One now automatically recognises and displays most of the graphic formats found on the Web, the supported formats can be seen in the screenshot.

Thanks for your work with the file descriptors. That is a good starting point. I have the datatype descriptor for my TIFF datatype . I just need to collect the files to compile and post them. I suspect TIFF datatype may work on AROS x86. Also I don't see HEIC in the list. Do we have it?

Here's some programming advice...

If the programs or features you are looking for aren't available and if no one is available to do the work then sometimes it's easier and faster to do it yourself. Seriously, if you have determined will to do it, you can succeed.

In the AROS programming area especially these things could take a long time since not many people are involved in development.

Here is a text file about AROS datatypes and it also describes my journey in C programming. As far as c programming just start writing and compiling and testing. It won't always work but sometimes it does! That's when it gets more interesting, when everything works.

As far as programming goes don't be afraid to fail. At times my failures are spectacular. Sometimes I crash AROS so hard there is no warning it just restarts. I wonder if the measure of a good programmer is how badly I can crash the operating system?

My recent work updating the PixieView program reminds me of some Picture Datatypes that may be useful. The SaveHAMPic function & the sub functions that I added to PixieView to Save As HAM (HAM6, HAM8) was originally written to include in ILBM Datatype when I was adding the Save_ILBM functions. There are two Save Functions: SaveBitmapPic & SaveRGBPic. SaveHAMPic would have been the third.

At the time I didn't add the Save As HAM code because it would make the ILBM Datatype too complicated by adding 1500 extra lines of code. However, it may be possible to write a new HAM Datatype. The only issue is the Datatype descriptor. It would pick up the ILBM file signature. It would be a complex descriptor to avoid that.

Also, TIFF Datatype works but currently TIFF Library is an external library that doesn't play well with MultiView. It may need to be converted to a shared library. That would allow me to update & post my TIFF Datatype. It works but it needs to support the multiple image format.

In addition, I still need to update & post the TGA (Targa) & PCX Datatypes. They have new save functions. I have to finish writing the Targa Run Length Encoding function to encode the files. PCX run length encoding also needs updating.

Lots of work to do for Picture Datatypes!

Thank you mike, regarding PixieView I noticed that it cannot be associated as a tool in the tooltypes, is this function planned for the future, if so due to its additional functions it could replace Multiview.

Do you mean "open with PixieView" like the def_picture icon DefaultTool lists MultiView?

I will have to figure out how that "Tool" identification system works. It may be different for Wanderer and Magellan. Magellan uses "Open with" and I'm not sure what Wanderer does.

It's a lightweight picture viewer/converter that is similar to MultiView using Picture Datatypes to display and convert images. But it isn't meant to replace MultiView because MultiView works with other types of Datatypes other than pictures. However, I like the Icon DefaultTool idea to open with PixieView. But there may be another way.

I'm thinking about updating MultiView to include the Edit menu item that reads the MultiView Icon looking for a ToolType EDITPIC= which can list PixieView as the picture editor. MutiView then sends the current picture filename to PixieView.

It would be good to test out both options. Open with... and MultiView Edit menu item. The ToolType must list the full path to PixieView. But the PixieView program needs to be revised to accept command line arguments for it to work. Maybe that's why the DefaultTool method isn't working as well. It has to use command line args to send a filename to open.

Don't replace Multiview on everything, but only on Images, I would basically add it in the def.icon dedicated to graphics.

Wanderer association is the same as on Amiga OS3, just click on the image, and it is much more convenient and faster than Open with diu Magellan.

I was hoping I could postpone it but I suppose now is a good time. I've looked at my sources for TIFF Datatype that I was writing a few years ago.

I'm going to take on a difficult task to rewrite the Datatype to use only native (internal) methods to load & save TIFF images independent of TIFF Library. I suppose I'm writing my own Lib Tiff. :-)

I will set a date of June 2025 for the completion of the new TIFF Datatype. I already have a working Datatype Descriptor for TIFF Images & the current TIFF Datatype works using Tiff Library.

Where can I find the Tif library, I don't have it?

He propably means dev libs f.e. for C, not shared libs

I have the compiled TIFF Library and TIFF Datatype in my VirtalBox test installation. I will post it when I find it.

I found TIFF Library now I have to compile TIFF Datatype for AROS x86. I will need to use the Build System (cross compiler) for the Datatype. It already has a DTD & makefile.src so it should be ok.

Previously I was using AROS x86-64 for testing. I will try to compile both x86 & x86-64 versions.

Tiff Library is already copied to the correct location on the AROS x86 I'm using for testing. It goes in Development/libs & Development/includes.

Here is the x86 library.

In the next few weeks I should have a working TIFF Datatype that doesn't use Tiff Library. There is a small program that I wrote called ViewTIFF that helps me to develop the needed functions.

Over the past several months I have been wondering about adding multi-image support to the PNG Datatype. Recently, however, I thought it might be better to make a modified Datatype instead called ICON Datatype based on it. ICON Datatype would use both WhichPicture & GetNumPictures so that we may selectively extract PNG images based on index values.

The difference between PNG & ICON Datatypes would be the DTD (Datatype Descriptor). For PNG it would look for png file signature & .png file extension. For ICON it would look for png file signature & .info extension. That should work.

TIFF Datatype will also use the Icon tags for multi-image support. The user can selectively extract Tiff images based on index values.

TIFF Datatype already works with TIFF Library to Load & Save 24bit uncompressed Tiff images. I tested the x86-64 version of the Datatype with my picture viewer application. But there is some strange behavior with MultiView.

If I try to open a Tiff Image with Multi-View immediately after starting AROS it will crash! Muti-View will freeze because it can't load Tiff Library.

However, here is the strange part. If I open a Tiff Image using TIFF Datatype with a Picture Viewer such as PixieView it works. It displays the Tiff Image just fine & it loads Tiff Library in memory. As long as the Picture Viewer & it's Tiff Image is still open then Multi-View has no problem opening Tiff images. Once Tiff Library is loaded in memory everything is fine with Multi-View.

I wonder if there's a way in Startup-Sequence using Load module to load Tiff Library in memory in advance? Then Multi-View should work ok. Or maybe use OpenLibrary/CloseLibrary in the TIFF Datatype itself to load the library in memory. If this is possible then I can use the TIFF Datatype. That would save me a lot of extra unnecessary work.

miker have you checked on other systems, can you send me in PM tif.datatypes to do some texting on my AROS One ? maybe I can find some shortcuts

Only the 64bit version has been compiled. Later today I can compile the 32bit version for testing & I can explain where to copy Tiff Library. On Icaros Desktop it is already available for 32bit.

I'm working at a computer store building computers till this afternoon. So it will be several hours till I have time to work on AROS things.

PixieView can use the TIFF Datatype to load Tiff images. If the Tiff Image is opened then Multi-View should also work with TIFF images. But Multi-View alone will crash! Use caution & expect to restart AROS One frequently. ;-)

I'm having some difficulty with the ABIv0 & ABIv11 Build Systems. I may need assistance in getting the Tiff Library compiled correctly.

What kind of issues are you having?

deadwood

I'm trying to compile my ViewTIFF, my TIFF Datatype & TiffInfo program. They require Tiff Library. Tiff Library is a link library in Developer/lib.

Judging by the errors I'm getting I don't think the compiler can find Tiff Library sources. And it complains that posixc.h can't be found & it can't find any Tiff Library includes. On ABIv1 ViewTIFF, TiffInfo & TIFF Datatype compile correctly. Tiff Library sources are in AROS/Ports I believe.

I don't know where to put the Tiff Library sources in ABIv0 & ABIv11. Is posixc.h being used? If Tiff Library requires it how can I get around that? Maybe that is in my makefile.src file. I recall seeing it there for TIFF Datatype. What can I substitute for posixc? I'm using some c functions.

Also, is there a way to pre-load Tiff Library in memory so that MultiView can use it to open Tiff images. Otherwise, MultiView can't open it & it freezes the system. Startup-Sequence, LoadModule, anything that might work?

It's weird that it's looking for posixc.h - if your library is using standard C functions (like fopen(), etc), these functions are defined in stanard headers like stdio.h, stdlib.h, etc. My suggestion would be to remove the include for posixc.h and replace it with relevant includes for standard C functions you are using.