Universal data exchange module

Universal Data Conversion module for RISC OS as standard module

I just saw in the bounty for !Paint, the implementation for PNG support. My programmer implemented just recently PNG support into !ChatCube.
So I see here a waste of resources in 2 ways:
a) waste of programmer workforce
b) waste of RAM as double, triple loaded code to do the same stuff. Depends on how many programs loaded need PNG support.

Furthermore lower performance as PNG decoding can be accelerated by NEON CPU code (which are included in new ARM SoCs).

One of the beauties of the RISC OS system was for me always that the operating system offers system call for many purposes.
So programmers don‘t need to program their own code and waste resources and possibly mess up the system as it happens in Windows.

So I would like that a module is included in RISC OS that all programmers can use to access images (load and save).
Priority is image formats but other data types should be also included like:
Vector files (SVG, AI, EPS, XARA, Artworks, CorelDraw, AUTOCAD … )
Sound ( MP3, MP4, WAV, AIFF, AU, PCM … )
3D data (DXF, STL, OBJ, FBX, COLLADA, 3DS, IGES; STEP, and VRML/X3D. )
Text formats (PDF, DOC, DOCX, ODP, CSV….)

This will speed up the development of new programs also significantly as programmers can concentrate on what they want to achieve and not waste months or years for just programming the data import or export.
This also must be decide what the internal RISC OS data format will be (Image, sound, vector, 3D and text).
For images would be probably Sprite format.

This module can offer also basic transition function for example:
Image files: brightness, saturation, gamma. etc.
Vector files: scaling, rotation
3D files: scaling, view point, wire/solid/rendered
Sound: …
There might be even a library that provides a user interface to access standard manipulation functions.
So the program just must call that library to offer additional basic processing features to the user.

The question is if we create a new module or use for example ChangeFSI as the base.
Another question is if we use one module for all types of formats or create separate modules (Images, sound, 3D, vector, text).

As an initial application, our conversion of GIMP could be used for that to start with the data conversion module with image files.

It is a good idea, especially if it utilised ChangeFSI in some form or another, for example utilising the existing API.

In terms of modularity, as you’ve already highlighted, perhaps where there’s no overlap in function then a separate module might be worth considering.

Also I’d propose a module that did filename and file path translation from/to other systems (Windows, Linux, …) might also be useful to developers.

Can I point out that there is already a bounty to add PNG export to ChangeFSI. It can already import them apparently.

Can you afford the autoCAD licence fees for this for vector files?

All text formats you mention are already available for conversion as far as I am aware.

I think we can do most of the Audio ones as well.

Ok the 3D stuff no we don’t have anything as far as I know, but can RISC OS actually do any of that stuff?

If you restrict your idea to only those computers with NEON CPU you cut off a large chuck of users.

I would far rather the existing bounties were completed as a first important step to move RISC OS forward. Invest in them first.

I know some will hate me mentioning this but ROL had implimented as a first step a image rendering system for multiple graphics types. Might help if that was transferred in to RO 5. Yes I know it was not perfect, it was first step. Yes I know everything ROL did was apparently bad.

Can I point out that there is already a bounty to add PNG export to ChangeFSI. It can already import them apparently.

Think Stefan is already aware of this as he stated:

I just saw in the Bounty for !Paint the implementation for PNG support.

I know some will hate me mentioning this but ROL had implimented as a first step a image rendering system for multiple graphics types

Exactly the point I made on the ROUGOL meeting ZOOM call last night that Stefan was on and hence what this is about I think.

In an ideal world that work would come across to 5 but it takes two or may be three to tango in this case so if that isn’t forthcoming then we just need to implement it in 5. Not ideal just reality though I don’t think there is a total no to it being made available just that it is tricky.

if you restrict your idea to only those computers with NEON CPU you cut off a large chuck of users.

It comes down to performance and if it means more modern machines get acceptable or better performance then that is just reality no matter how we may wish it to be some older machines may not just be up to the task.

The same issue is found for newer heavy weight browsers older machines just are not going to cut it and even some newer hardware that utitlises SDCard storage isn’t going to cut it either.

If it can be done and not at the expense of making newer machines even better and desirable then I agree do it as it is better to support as many as possible but sometimes we just have to be realistic and not nostalgic.

There are already converter apps – it’s how the Progs like Ovn/Imp use them.

TechWriter just uses the convertor Progs as required – and leave’s the imported file alone.
Saving it as is in the TechWriter file.

There are already converter apps – it’s how the Progs like Ovn/Imp use them

There are but this is about implementing it as a standard OS function aka Select/RO6.

It is then supported in the OS and does not come down to if that app is manitained or not.

Also if it is a OS function one would expect a standardised API to access the functionality and make it available to any programme though if there is an existing API that looks good then just bring that in to the OS.

I would look at Select/OS6 and use that API where possible and then hopefully we don’t need to split the functionality any more than it is.

As an initial application, our conversion of GIMP could be used for that to start with the data conversion module with image files.

Unless I’m mistaken GIMP is a GPL code item and as such the code couldn’t be used as part of the OS.

If you restrict your idea to only those computers with NEON CPU you cut off a large chuck of users.

I’d suggest that the proposed code should target the available facilities in the SoC, be that NEON or other.
Code it with a fallback to (slow) simple operation on systems without. No one misses out, but old systems have a speed penalty.

I know some will hate me mentioning this but ROL had implimented as a first step a image rendering system for multiple graphics types. Might help if that was transferred in to RO 5. Yes I know it was not perfect, it was first step. Yes I know everything ROL did was apparently bad.

Replicating and extending the functionality of the ROL conversion facilities is a good idea.

If the source was available it might be useful in a project for a more comprehensive converter.

Think Stefan is already aware of this as he stated:

I just saw in the Bounty for !Paint the implementation for PNG support.

Actually there is a specific bounty for PNG support and it says to be added to Paint and ChangeFSI, but the work on PNG support for Paint must be done in association with the person doing the paint bounty.

if you restrict your idea to only those computers with NEON CPU you cut off a large chuck of users.

It comes down to performance and if it means more modern machines get acceptable or better performance then that is just reality no matter how we may wish it to be some older machines may not just be up to the task.

As someone else has just pointed out it should be coded to use NEON where possible but allow the facility to be used on slower/computers without NEON and they have to accept a slower performance if they want to use the feature.

Regarding making it an OS function then in general that is a good idea and rather then reinvent the wheel, be able to use the work alredy done by ROL would save time and effort.

I think RISCOS Developmemts need to talk to Aaron about this as RISCOS Dev are supposed to own the OS now.

Regarding GIMP it is GPL, but can be made for use on RISC OS but NOT added to the OS itself. GIMP is very much a heavy weight program so only the newest RISC OS computers will be able to use it with lots of RAM.

Isn’t this idea basically ImageFS?

Isn’t this idea basically ImageFS?

Indeed its very similar I think ImageFS2, from rusty memory was claimed to be part of the basis of the Image Renderer system used in RO 6. I might even still have a copy somewhere on my virtual machines.

Has anyone received an email from someone claiming to be from Cloverleaf RISC OS.
Christine Faith Lopez (removed email address) it was sent to one of my accounts – I am treating it as spam. Wanting me to go to a Facebook page.

I do not do facebook normally only for family.

Editted from origianl post.

from someone claiming to be from Cloverleaf RISC OS.

Yes. And it included a link to a RISC OS appropriate video of mine on YouTube. So I’m considering it as not spam, but possibly the Cloverleaf people trying to reach out to various “names”.

Christine Faith Lopez <cfaithlop[…]

Yup. That’s the one. Though, really bad form to drop people’s emails in public in an unmangled form.

Wanting me to go to a Facebook page.

Yes, the Cloverleaf Facebook page. Easily sussed by checking the link really is to Facebook, and then following it in private mode with full content blocking in place.

However… About that.
I don’t do Facebook.
I don’t do proprietary walled gardens.
Did I mention that I don’t do Facebook? I don’t trust them, and a pretty good way for me not to trust you is expecting me to sign up for a closed service on a site of dubious character…

Or, in case that’s too many words for this time of the night, “f**k Facebook” ought to about cover it.

Stefan says she does marketing for them.

You could have asked Stefan on ChatCube, like I just did!

You would have thought a name like that would have been kind of unique… Well, all I could find is two Filipino girls, one the Business Development Head at Comworks and the other a crochet artist. I’m not really seeing any RISC OS connection there… Though a crochet cog would be kind of cool…..especially if some coloured LED ribbon was intertwined in it to animate itself afterwards – I’m a sucker for blinky lights ¹.

¹ The WOPR is my idea of what a big-ass computer should look like. Lots of lights…

Stefan says she does marketing for them.

Ok (removed original text as it was considered offensive)

You could have asked Stefan on ChatCube, like I just did!

I do not do chatcube at this time.

Christine Faith Lopez <cfaithlop[…]

Yup. That’s the one. Though, really bad form to drop people’s emails in public in an unmangled form.

Sorry, (removed more text due to tone of post was not fair). If it had come from a Cloverleaf email address I would not have been concerned.

Ok well it was a poor email to be honest

Stefan did say he would feedback on the emails to the person he had engaged to do this as it was mentioned on the ROUGOL call last night.

As someone else has just pointed out it should be coded to use NEON where possible but allow the facility to be used on slower/computers without NEON and they have to accept a slower performance if they want to use the feature

You seem to have missed me making the same point sort of :-)

if it can be done and not at the expense of making newer machines even better and desirable then I agree do it as it is better to support as many as possible

Sometimes though the feature will just not make sense to implement after all there are things a RiscPC can do that a A310 can’t like play MP3’s for instance cause it hasn’t got the grunt to do so unless someone comes along and tells me differently.

The example for Neon was 3D graphics rendering which you would be pushed to do on a RiscPC or earlier.

Something like MPlayer though could just fall back and give a smaller video output unless you like slow motion video and sound :-)

The secret is knowing when to implement a fallback or feature restriction, if you can, and when to say enough is enough and time to spend some money on a new machine.

If someone doesn’t want to do that then they just don’t get all the newer features but they haven’t lost anything they can do today it just means they can’t do everything others can.

isn’t this idea basically ImageFS?

Again that was mentioned but if it is OS implemented and supported then that is better and it was scoped as something more than just image formats.

As I said it is a shame the ROL image file renderer
stuff isn’t available as it is one of the things I miss about Select that just gave it a better overall feel.

using a Gmail account no less, not professional to me

Everyone uses GMail accounts these days: away from the anachronistic RISC OS scene, I can think of only two other people who don’t now use one of the big Cloud services. I’d consider most of them professional.

Though, really bad form to drop people’s emails in public in an unmangled form.

Yup. Might be polite to redact it from the original post, Chris.

Yes, the Cloverleaf Facebook page. Easily sussed by checking the link really is to Facebook, and then following it in private mode with full content blocking in place.

Indeed.

That said, FFS… Can’t we manage to promote our platform in a positive way, without relying on dated stereotypes which were questionable twenty years ago and demonstrably false now?

…sorry, got to go… I think that’s the 1990s calling to ask for their anti-Windows ^H^H^H …anti-Windoze negativity back.

!

Just to be clear these were personal posts from me not the Club/Show.

I have removed the offending email address from my post.

…sorry, got to go… I think that’s the 1990s calling to ask for their anti-Windows ^H^H^H …anti-Windoze negativity back.

Its got nothing whatsoever to do with anti-windows.

Its got nothing whatsoever to do with anti-windows.

And there was me thinking you hadn’t looked at the Facebook page…? All I could see was negativity about other systems; nothing about why you might want to tinker¹ with RISC OS alongside them.

¹ Let’s not kid ourselves; it’s not a Windows, MacOS or Linux replacement just yet.

And there was me thinking you hadn’t looked at the Facebook page…? All I could see was negativity about other systems; nothing about why you might want to tinker1 with RISC OS alongside them.

I do not look at Facebook pages that are from an unknown person, I only use facebook for family and a couple of friends nothing more.

I have not mentioned any other systems in my posts. So no idea where that idea has come from.

I do not use ChatCube from choice at this time. I use whatever OS does the particular job best.

Every day I see emails from ‘professional services’ people like web designers, SEO specialists and app developers touting their services and products. If it comes from a gmail/outlook/hotmail/yahoo email domain I bin them instantly without reading them as I see it as unprofessional. It doesn’t take much to get a personal/commercial domain and front that onto a gmail or whatever account in the background. A private domain has a whois lookup that tells me a bit (not as much now as it used to) that gives me some degree of confidence in the outfit. A gmail address is untraceable with no history or location of the user. I have a few gmail, hotmail and outlook addresses myself, but I don’t use them for business purposes, more for anonymising purchases and enquiries on web forms.

I also have no intention of joining any social media (data harvesting) site.

I should also add that I like the idea of an OS-wide image converting module that can be used from any application.

Erm, didn’t Select have this years back, probably over a decade now.

I am pretty sure a lot of work went into doing so, but the problem is now that work is to all intents and purposes “lost” because we don’t (legally) have access to the sources for 4 and it’s deriviates.

I am pretty sure it was well documented, but I am sure what the legal implications would be to do a rewrite against the same API. It would seem to be more sensible than to reinvent a wheel?

Something similar could be done for audio files.

I think the Amiga had something like this decades back too.

I suppose we’d be looking at something like a Shared Image Processing Library and a Shared Audio Processing Library, both with softloadable supporting modules to add new functionality/file type support to make them extendable.