Login
Username:

Password:

Remember me



Lost Password?

Register now!

Sections

Who's Online
118 user(s) are online (59 user(s) are browsing Forums)

Members: 1
Guests: 117

MickJT, more...

Headlines

Forum Index


Board index » All Posts (Wanderer)




Re: Scaling many pictures
Just popping in
Just popping in


ImageConverter:


ImageConverter DH0:MyFolder/#?.tif -w 800 -h 600 -of DH0:800x600/%f.png -f PNG


- requires TIF Datatype
- saves only as JPEG, PNG, IFF-ILBM and BMP
- handles Alpha Channel correctly and saves it in IFF-ILBM (ArtEffect compatible), PNG, BMPv5

Aspect ratio is preserved, 800x600 would be max dimensions.
Many other options are possible.

Same code as iBatch, only CLI Tool and not GUI.

Go to top


Re: iBatch (Image batch processing tool) update + support thread
Just popping in
Just popping in


Sorry, the docu is wrong here.

The compression parameter for image_Save depends on the file format. (maybe I should change this?)

BMP: always uncompressed
PNG: 0=no compression, 1...9=zlib compression depth
JPG: 0...100 JEPG quality parameter, 0=week, 100=strong compression
AB3I: like PNG

JPEG always compressed, even with compression set to 0.

Go to top


Re: iBatch (Image batch processing tool) update + support thread
Just popping in
Just popping in


Using Tabview is a good idea to not overload the options that are displayed at once.

Some ideas:

1. JPEG comression is never "None". Even with compression set to 0, it halves the color resolution. So, low ... high would be appropriate.

2. The resulting file name should be a template, similar to C, but with a set of placeholders (that must be visible via online-help).

E.g.

%f : original file name stem
%d : file date
%w : conversion max width
%h : conversion max hgeiht
%i : image index counter
...

so you can write your new output filename like:
"Lanzarote_%i_%wx%h"

=> "Lanzarote_124_800x600.jpg"



Go to top


Re: Video editing software bounty?
Just popping in
Just popping in


I was thinking for quite a while to add video tracks to HD-Rec. That would be a fully featured editor and would allow complex audio editing.
However, the idea always suffered from a usable decoder/encoder library. It doesnt need to suport all codecs in the world, but some common ones for decoding and for encoding a fast, high-quality one plus a "release" one, like mpeg4.

Resized Image

I have alreay written a couple of effects:


Resized Image

Go to top


Re: Best sound card for *recording* on a Sam?
Just popping in
Just popping in


If USB is supported, I would go for an USB soundcard.
Benefit is that you can use it everywhere, not only the SAM, and you might be willing to raise your budget in that case.

There are thousands of good soundcards out there.
If it needs to be on professional level, try the cakewalk UA25 EX.

http://www.rolandus.com/products/prod ... roductId=970&ParentId=436


Go to top


Re: iBatch (Image batch processing tool) update + support thread
Just popping in
Just popping in


Have you compared he speed between no interpolation and window interpolation?

If the sharpness parameter is 0, it should be pretty fast.

if the scaling factor is smaller than .5, you could speedup by rendering an intermediate bitmap by using image_Half{}, which is extremely fast. E.g. if you are generating thumbnails, better to do image_half, and then resize, this would speed up window inteprolation or would increase quality for no interpolation.
If needed, we could think about implementing "image_Quarter" too.

Go to top


Re: iBatch (Image batch processing tool) update + support thread
Just popping in
Just popping in


@Gero

And dont forget to restrict to window resizing. Otherwise people might keep complaining about the image quality.

--
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
Go to top


Re: A possible bug in the p96 GetBitMapAttr function
Just popping in
Just popping in


@Deniil

.. which is correct. The color depth is usually 24bit on a 32bit screen. Dont mix it with the bits/bytes-per-pixel, which can be querried seperatly by LockBitmapTagList().


Edited by Wanderer on 2010/11/14 19:32:29
Go to top


Re: program to convert 8 bit AIFF files to 16 bit ?
Just popping in
Just popping in


@328gts

=> Audioconverter does exactly what you need.

It support AIFF, WAV, MAUD, 8SVX, MP3 and several other formats from/to different bit resolutions and samplingrates.

Go to top


Re: program to convert 8 bit AIFF files to 16 bit ?
Just popping in
Just popping in


Use something developed on Amiga for Amiga:

http://www.hd-rec.de/Archive/AudioConverter.lha

The Command line would look something like this:
AudioConverter DH0:Sounds/#?.aiff -f AIFF -db 16 -dd DH0:Sounds16Bit

Go to top


Re: Amiga Youtube videos
Just popping in
Just popping in


@Chris

What's that speechsynthesis? The command line tool look somehting like "fsay". Is it flite-based?

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just popping in
Just popping in


@Wanderer

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.

Resized Image


And here you can compare them better zoomed:
Resized Image

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.

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just popping in
Just popping in


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).

Resized Image

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
Resized Image

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.

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just popping in
Just popping in


@Rigo

I think you missed the word "besides" in Amigo1's post.

But this thread here is about AISS, not a gerneral "how-to-solve-all-Amiga-Problems" ranting thread.

Let's wait and listen what Mason has to say, if he is willing to draw the icons at higher resolution. Mason?

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just popping in
Just popping in


@saimo

> 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
Resized Image

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.

Resized Image


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.

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just popping in
Just popping in


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.

You could get something like

BitMap *bmap aiss_ObtainBitmap("TBImages:disk",21,AISSFX_GLOW);


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.

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just popping in
Just popping in


@saimo

> Well, I wouldn't say so:
But I would say so

See the difference:

regular / GUI-algo / original
Resized Image

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
Go to top


Re: Icon Wunschkonzert - AISS Edition
Just popping in
Just popping in


@saimo

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.

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just popping in
Just popping in


@Amigo1

NTUI is the GUI Toolkit I am working on, it is not yet released. It has on-the-fly image rescaling build-in.
The screenshots above of the filemanager are made with NTUI. I wanted to demonstrate how useful scaling of images is. Those screenshots are impossible with any other toolkit on the Amiga AFAIK. All other Toolkits would use the 21x21px images, which would look very bad and waste a lot of space in this example.

So having this functionality via aisscache.library would be very handy for other Toolkits, unfortunately only for those which are still developed and would make use of it.
Because of this, it would be at least handy to be able to adjust globally the size to your Workbench Font/Screen resolution/DPI.

Go to top


Re: Icon Wunschkonzert - AISS Edition
Just popping in
Just popping in


The aisscache.library would be the right place to add on-the-fly rescaling and postprocessing support.

The problem is, not all progs use this, and it must be available to OS3, MOS and AROS too.

I also thought about the problem with too large scaling.

What about this directory structure:

TBImages:

Here are the default images in 21x21 (or what the uses sets during install/prefs) this is for backward compatibelity, programs that dont use aisscache or dont care.

TBImages:<size_in_px>/

Here are the images in various sizes, if any variations needed that cannot be obtained by scaling.
The folder name reflects the pixel size, just like bitmap fonts.

If you want to do a different (not obtained by scaling) image for 16x16, you store it here:

TBImages:48/myimage
TBImages:16/myimage

If the aiss.library gets the request to access the image "myimage", it would transprently choose the best-fit. Because we would allow only down-scaling, that would be the 48px image for 17-48, and the 16px image for 1-16.

You can also store _s and _g variants, but if they do not exist, the aisscache.library could create them on-the-fly by applying the effects that the user has set in prefs.

This is very similar how I implemented this already in NTUI.
In the NTUI Toolkit you dont set pixel sizes. You set logical sizes.

E.g. you have the sizes
NTUISIZE_INLINE
NTUISIZE_NATIVE
NTUISIZE_TOOLBAR
NTUISIZE_PIXELS

"inline" would return an image that is scaled so that it fits into floating text, like you can see in the listview in the Filemanager Mock-Up.

"native" would return the actual size the image file has.

"toolbar" would return the size that is set for toolbar images in NTUI Prefs.

"pixels" would return a size corresponding to the acutal given pixels.

etc. there are some more sizes of course.

E.g. you want a smily for a chat-application.
Then you would request "inline". Whatever you current font is, you would get the "native" image scaled to your font size. Just one big smily image would be enough then. No need for a "listview" version etc. what Mason currently has.

Such a concept would be really good for other GUI Toolkits too, and Mason has to paint less images.
Also think about that an active and a disabled version is not really enough. In NTUI, I have also the states "focused" and "mouse-over".

Now, what I suggest is that we make a small "proof" of concept.
If Mason would paint a hand full of images at large size, say 48 or something, and I will rescale them and post-process them, I can also do 5 states instead of 3.

Then we can compare them to their original AISS counterparts and see if we can match the quality, or maybe even exceed it.
@Mason
What do you think?

I know the topic is complex, the above is just some brainstorming, not a ready-brewn concept.

Go to top



TopTop
« 1 (2) 3 4 5 6 »




Powered by XOOPS 2.0 © 2001-2023 The XOOPS Project