Yes, makes sense, but since I am excluded from using OS4 because I refuse to buy a PPC, I have to stick with OS3. And if I write a library/GUI Toolkit/etc., I want to use it under OS3. And for all other developers it makes sense if this library/GUI Toolkit/etc. is availble with a consitent API to MOS and AROS as well. Because what Hyperion developes will be OS4 exclusive, it is unable to become a defacto standard.
E.g. AHI became a defacto standard because it is available on all systems. Same like cybergfx library or MUI3.
So if a new GUI Toolkit is developed, it makes only sense if it is available to all platforms. Anything else is a slam into the face of all Amiga developers.
@EDIT The scaling functionality I presented above it optimized for GUI images. If you try to do the same with a regular scaling algorithm, the result will be significantly worse. On the other hand, you wouldn't want to use this algorithm for Fotos, Backdrop images or alike. So we would be already at a point were you have to introduce new code and new Tags to set the algorihm in BitmapScale() or whatever.
I think a dedicated aisscache.library makes sense.
Yes, makes sense, but since I am excluded from using OS4 because I refuse to buy a PPC, I have to stick with OS3. And if I write a library/GUI Toolkit/etc., I want to use it under OS3. And for all other developers it makes sense if this library/GUI Toolkit/etc. is availble with a consitent API to MOS and AROS as well. Because what Hyperion developes will be OS4 exclusive, it is unable to become a defacto standard.
E.g. AHI became a defacto standard because it is available on all systems. Same like cybergfx library or MUI3.
So if a new GUI Toolkit is developed, it makes only sense if it is available to all platforms. Anything else is a slam into the face of all Amiga developers.
Sorry, I had totally forgotten the platforms you were targetting. Anyway, the most important point of what I said still stands: implementing image processing functions in a specific library is the best choice in general, so, if there is no particular reason to be against it, I'd really consider it. And, as an added bonus, such a modular design helps a lot in OSes cross-pollination and establishing de-facto standards
Quote:
The scaling functionality I presented above it optimized for GUI images. If you try to do the same with a regular scaling algorithm, the result will be significantly worse.
Well, I wouldn't say so:
(And that's just by brutally scaling the whole rightmost column in your previous example.)
Quote:
On the other hand, you wouldn't want to use this algorithm for Fotos, Backdrop images or alike.
If you have a good algorithm, then it's one more reason to think exactly the opposite way: don't restrict its possible uses You never know how useful it could turn out to be to others.
Quote:
So we would be already at a point were you have to introduce new code and new Tags to set the algorihm in BitmapScale() or whatever.
I can't see why. You said you're creating a GUI toolkit, so what problem would you have calling the scaling function from the imageprocessing.library?
Quote:
I think a dedicated aisscache.library makes sense.
That would be a seriously flawed design choice: the purpose of the aisscache.library is totally different, so putting there any image processing functions is a wrong move.
The details get smashed in a regular scaling algorithm, while they are preserved as much as possible with the GUI scaling algorithm. E.g. you can still see the slot in the blue prefs-switch-emblem, or the handles on the drawer. Or the black head and the eraser of the pencil. They get completely smashed in your algorithm. Don't forget if you scale to such small sizes, you probably have a low resolution were you see everything at lower DPI, every pixel counts!
Also the strength of the algorithm is not to scale from 48 to 16, even though it is still better. The stength is to scale e.g. from 48 to 45 or something like very odd scaling factors. Normal "resampling" algorithm will smash the pixels. Everything becomes blured and colors smear into each other, everything gets grayish.
Edited by Wanderer on 2010/9/10 10:52:57 Edited by Wanderer on 2010/9/10 10:57:46
Putting the funtionality into a general imageprocessing library would be the most flexible, I agree. But it is much easier for developers if this is integrated into e.g. the aisscache.library, as a general library to access AISS images.
If you have several libraries, this can easily blow up. It would be also more handy to get directly a set of bitmaps, one for each state. And there we are already specialized to the GUI image concept.
This is a general problem on the Amiga. The OS itself it too weak, so developers start to make themselves dependend on unreliable 3rd party libraries or implement the wheel again for them selves. I ran a lot of times into a dead end because I discovered a bug in a 3rd party library or had some missing features, and the library was not developed anymore. At the end, I implemented a huge library for everything by myself, which is now the modern runtime of Amiblitz.
I agree to that, in fact what I was trying to say with my post was, if Hyperion has not the man power to address that ATM, why couldn't this effort (and in this case NTUI) go through Wanderer or e.g. openamiga? I share definitely your opinion that one GUI-Toolkit should be set as standard. I know it's currently Reaction, but in the opinion of the majority it isn't that optimal at all. Besides the software that comes with the system, very few use Reaction AFAIK.
At the end it would be sad to see another toolkit (this time NTUI) which the author will spend hours in developing just or mostly for his how use. Obvious result of this, is that OS4 develops very slowly.
Quote:
saimo wrote: @all
Sorry if I repeat the following concept, but it's an important one.
Any image processing function (scaling, shadowing, rotation, glow, you-name-it) should go in a specific library that is oriented precisely and exclusively to image processing - let's call it imageprocessing.library. Then, any GUI toolkit, icon.library, game, application, whatever, can simply use the services offered by such library. Such library should be evaluated together with the OS development team, since the whole graphical subsystem is being / will be reworked. Same goes for any GUI toolkit: we already have too many and we already know that the OS does and will provide an official toolkit (whichever it will be), so the best thing to do is checking with the OS developers.
I don't mean to discourage initiatives by enthusiast developers, but avoiding wastage of energies and potential splits, and possibly contributing to a clean, system-rooted, unified solution is highly recommendable.
EDIT: just as a practical example, let's consider scaling: the OS already has that function somewhere - why would one want to duplicate that functionality anywhere else? And if it's only because the already existing functionality isn't exposed as a general-purpose service, then, well, the right solution is not re-implementing the functionality, but moving the existing one to the right place.
First of all, let me state clearly that I'm in no way questioning the quality and usefullness of your algorithm - actually, I'm happy to know there's one more smart algorithm in Amigaland
But I have also to say that the previous example I posted was just a quick mass-scaling done without particular care* to show that the result would not be "significantly worse": the icons aren't much harder to read than those output by your code.
*I just cut the rightmost column without paying too much attention to the size of borders and fed ImageMagick/convert with the picture, asking it to scale it to a width of 20 pixels.
Of course, a better scaling effort gives better result - the results of the Lanczos algorithm (still starting from the rough source picture) are very close to yours:
(I can't bother to show it zoomed )
Anyways, this has not much importance. Again let me say that if you have a good algorithm, it's one more reason to make it easily available as a general-purpose function.
Quote:
Putting the funtionality into a general imageprocessing library would be the most flexible, I agree.
That's not the only advantage: clarity, portability, maintainability, performance, etc. are other important factors.
Quote:
But it is much easier for developers if this is integrated into e.g. the aisscache.library, as a general library to access AISS images.
If you have several libraries, this can easily blow up.
Making a design choice using laziness of programmers as a deciding factor is wrong.
Now, regarding the example you made: 1. first off, that function doesn't belong to a caching library, but to an higher level one which provides "rich" access to images, so the first thing to do would be calling the library with a proper name - let's say imageutility.library; 2. secondly, you can surely have a function of the kind you proposed: just make sure the glow functionality isn't in the library, but in the image processing library.
Note that such modularity allows also things like: * GUI toolkit -> imageprocessing.library * other OS component -> imageutility.library -> imageprocessing.library * other OS component -> imageprocessing.library * application -> imageutility.library -> imageprocessing.library * application -> imageprocessing.library
Quote:
This is a general problem on the Amiga. The OS itself it too weak, so developers start to make themselves dependend on unreliable 3rd party libraries or implement the wheel again for them selves. I ran a lot of times into a dead end because I discovered a bug in a 3rd party library or had some missing features, and the library was not developed anymore. At the end, I implemented a huge library for everything by myself, which is now the modern runtime of Amiblitz.
Precisely because of these problems it would be better creating "simple", clean, modular, non-overlapping libraries. Just consider how easy it would be porting the imageprocessing.library to the various Amiga OSes and how more difficult it would be to port a library that, instead, besides image processing, also depends on AISS and possibly other GUI/system stuff.
> Of course, a better scaling effort gives better result - the results of the Lanczos algorithm (still starting from the rough source picture) are very close to yours: Actually not. It is better, but still much closer to your previous example. I bothered to scale it up:
regular / lanczos / GUI alog /original
Also, you have (accidently?) choosen an integer ratio of 1:3 for scaling, which is very welcoming for scaling.
And it is of importance for the overall look, and the main reason why Mason probably hesitates to draw larger icons - simply because the scaling quality destroys details of his artwork. GUI images, in constrast to fotos for example, contain a lot of high "frequencies", like one-pixel lines etc. This is bad for scaling, and what my algo keeps to preserve.
If you would take e.g. the notebook with the pencil, and display it to 100 random people. I bet that the version from my scaling alog will be more often identified as "a notebook + a pencil" than the other versions.
But generally, I agree to you. But this is just a huge organizing problem. If I, as a nobody, would write such a library, who would gonna use it? Hyperion? I doubt. The real problem we have here is to set high-leveled standards. The standards we have are all very low level. Even AHI is very low level compared to other APIs. We dicussed this in another thread already.
I share definitely your opinion that one GUI-Toolkit should be set as standard. I know it's currently Reaction, but in the opinion of the majority it isn't that optimal at all. Besides the software that comes with the system, very few use Reaction AFAIK.
I'm not sure what point you are trying to make here, but all OS components current use the BOOPSI class collection formerly known as "ReAction".
There are a number of contributions that use MUI, YAM, IBrowse, SimpleMail etc, but the OS components use the OS GUI toolkit.
Simon
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
Regarding the algorithm: * again, I'm not questioning the quality of your algorithm; * no, I didn't choose any ratio - as said, I cut the rightmost column without paying too much attention; since you ask, here's the source bitmap:
(the width is 57 pixel, which don't scale nicely to 20 at all).
Quote:
But generally, I agree to you. But this is just a huge organizing problem. If I, as a nobody, would write such a library, who would gonna use it? Hyperion? I doubt. The real problem we have here is to set high-leveled standards. The standards we have are all very low level. Even AHI is very low level compared to other APIs. We dicussed this in another thread already.
One may define any standard, one may create any library, one may design whatever he wants: still, at some point, "who would use it?" would be asked. That's no a reason for giving up good design. And - excuse me if I repeat it again - actually a good design makes porting a lot easier, so the question "who would use it?" has chances to get an answer Apart from the fact that I can't see why the OS developers wouldn't listen to you at all beforehand, just imagine: if an imageprocessing.library, with glow, scaling and whatnot were available right now (without license problems, that is), how long do you think it would take to port it to all the AmigaOS flavours? - and that would surely ring a bell to the OS developers; on the other hand, if you make a complex piece of OS with plenty of dependencies and possibly overlapping/clashing with certain other OS parts, it's much more unlikely to be taken into consideration for an official endorsement. In short, if you really wish to target multiple platforms, keep it simple, stomp on the OSes feet as little as possible, try to talk to all the involved parties and don't be afraid
Actually, I spotted the "Besides", it was the comma after it (or lack of) that threw me.
Point taken, I'll shut up now :P
Simon
Comments made in any post are personal opinion, and are in no-way representative of any commercial entity unless specifically stated as such. ---- http://codebench.co.uk
Just out of curiosity, I did the following experiment:
I repainted the "TBImage:save" image in 96x96 pixels, this is 4x larger than the original. Then I made a chart comparing them at different sizes (of course, the AISS images dont look good at sizes >24px) and made a comparism of the original AISS size (which is 24px) to the down scaled version (2nd pic).
Actually, to me the 24px scaled version looks almost as good as the hand-drawn AISS image or even better (however the base image is slighlty differnet...)
_ AISS / re-paint / re-paint 2x
So even if you plan to distribute only 24x24, drawing at larger sizes is good to have something for backup if requirements change, e.g. screen DPI doubles, or people want to use larger images for different purposes.
Another comparism, tried to make them more similar, removed the lines (this is actually a real hard thing for scaling algos). I also made the edges smoother, they were drawn as rectangles in the first quick draft.
And here you can compare them better zoomed:
Still, I think that the 24px version manually pixeld is not significantly better than the downscaled version, so that you should not have the higher resolution ones. When using in Apps like an Emailer e.g. I find the 24px quite small on my screen already. 48px would still not be too big. And e.g. on TouchScreens (that will be sooner or later often used, e.g. on Tablet PCs), even the 96px would be good to have, since you are not as accurate as you qould be with the mouse.
Next time you are taking requests, can you do one of your "listview" style icons (the small ones) for: Left mouse button Middle mouse button Right mouse button
and maybe "mouse wheel" and the crazy extra side buttons ("back" and "extra" I believe OS4 calls them)
If the Assign Script for "TBImages:" would assign the "Sys:Classes/ToolbarImages/Contrib/" folder FIRST, the user could easily override AISS images with custom ones.
Right now, it is the opposite, the "Default/" drawer is assigned first and has precedence. Means there is no way to transparently override default AISS images, if not replacing the original ones.
If Mason is reading this, I would like to point out some images that have not worked well for me, including the explanation why, so you could consider improving them.
There also a few missing for my upcoming AIDE app.
All in all I must say, AISS is quite a good collection of icons. I made some experiments, overriding AISS images with different icon sets, e.g. OpenIcons, but they all look either only good in high resolutions and screw up in 24x24, or just look old, boring, unrecognizable and inconsistent.
Conclusion: good job, Mason. AISS is awesome!
-- Thilo K?hler, author of HD-Rec, Sweeper, Samplemanager, ArTKanoid, Monkeyscript, Toadies, AsteroidsTR, TuiTED, PosTED, TKPlayer, AudioConverter, ScreenCam, PerlinFX, MapEdit, AB3 Includes and many more... Homepage: http://www.hd-rec.de
At least in AmigaOS4.1-world this isn't supported anymore since ... I suppose OS4.1 Update 1 (I'm not sure). The only assign left for "tbimages:" is "SYS:Prefs/Presets/tbimages".
Next time you are taking requests, can you do one of your "listview" style icons (the small ones) for: Left mouse button Middle mouse button Right mouse button
and maybe "mouse wheel" and the crazy extra side buttons ("back" and "extra" I believe OS4 calls them)
I wish I could remember why I was asking for those.
Probably for your magic-themed point&click adventure game where one would be able to set different spells to the mouse buttons used explicitely in fight scenes.
The icons you requested were for your interactive game manual.
@Mason
Will there be a new AISS soon(-ish) or maybe another Wunschkonzert?
The more I work on NTUI, the more I realize how important AISS is for the future of AmigaOS. Without AISS, Apps would look really poor. I think this is more important than yet-another-bunch-of-icons.
BTW, have you tried to make the listview version by scaling? I do this all the time in NTUI and it looks quite well.
News feed
OS4 Feedback forum
OS4Depot Feedback forum
Amigabounty forum
OpenAmiga forum
AmiCygnix forum
ABC shell forum
AmiKit forum
Cinnamon Writer forum
CodeBench forum
Digital Universe forum
Dopus 5 forum
E-UAE forum
Gnash forum
Ibrowse forum
JAmiga forum
Odyssey forum
OWB forum
Qt forum
SmartFileSystem forum
Timberwolf forum
TouchDevice forum
TuneNet forum
Unsatisfactory Software forum
Donate
)
