icon.library 46.4 test versions

[mfilos]

There you go Peter my friend...
This time is indeed grayscaled

[Bamiga2002]

Thumbnails dude, THUMBnails!

Great work! I'm addicted to this icon.library, can't switch on my miggy without it

[matthey]

Originally Posted by PeterK

@ClarkKent71
Just made an update to the grayscale calculation. It's now equal-weighted for the three color components RGB, 33% for each of them. Red was overweighted before, because I didn't want to use an extra DIVU instruction. Maybe, I will find a better solution later and a way to make gray an option.

Hi Peter. I've been playing with some assembler DIV instruction replacements lately. If you are dividing by a constant, you can do an invert (reciprocal) and multiply instruction instead but may lose some precision. For example,

divu.w #3,d0

to:

mulu.w #$5555,d0 ;multiply times the reciprocal/magic value 1/3 (16.16 fixed point)
swap d0 ;d0.w is ~d0/3

You don't get a remainder and the accuracy can be off a little in some cases as 16 bits isn't enough for 100% accuracy but it's very close. A longer reciprocal will improve accuracy but a 32x32=64 bit multiply may be necessary to avoid overflow. More accurate version:

mulu.w #$aaaa,d0 ;multiply times the reciprocal/magic value 1/3 (15.17 fixed point)
moveq #17,d1
lsr.l d1,d0 ;d0.l>>17 is ~d0/3 (16.0 fixed point)

Here is how to calculate the 16.16 fixed point reciprocal to use for 16 bit numbers:

move.l #$10000,d0
divu.l #constant,d0 ;d0.w is your reciprocal/magic value

Don't forget that division by powers of 2 can usually be converted into shifts (watch out for signed numbers though). There isn't much that can be done if the numerator (top number) is a constant or both arguments/ops are variables. I hope it helps. Let me know if you have any questions.

[mfilos]

Originally Posted by Bamiga2002

Thumbnails dude, THUMBnails!

EAB doesn't generate automaticaly thumbnails when you insert an IMG tag from an off-site URL... DOES IT?...

The thumbnails are auto generated when you insert an image via EAB's attachment feature.
Sadly the attachment quota is rather low, so you'd have to delete every once and a while, which is something I'm actually bored doing.

I'm not uploading enormous screenshots. 800x600 resolution is ok for every web browser. Also all screenshots are PNG and between 100-200KB so no bandwidth issues as well.

[Retrofan]

Your images are perfect mate. Anyway I don't like and don't see any future for these gray scaled icons; I want colour.
Well, if I could have a transparent menu like AfA does (offtopic), then I don't need colours for that.

[PeterK]

Originally Posted by mfilos

EAB doesn't generate automaticaly thumbnails when you insert an IMG tag from an off-site URL... DOES IT?...The thumbnails are auto generated when you insert an image via EAB's attachment feature.
Sadly the attachment quota is rather low,...

EAB has never rejected any of my attachments yet. Please use this feature, because your large images tend to tear the thread apart. (Btw, Retrofan likesto do that, too). It makes reading the thread and following the discussion less pleasant.

Update for mfilos
Hey, that's really funny now! You've removed all your images but EAB still remembers the size of them and reserves the space for these screenshots. What a tragedy, it didn't help to remove them to rebuild the thread as expected. So, I hope you don't get upset by this discussion now since I really like your feedback very much and I'm always happy to get any replies here.
Hmm, right now, all your images are back again. Was your image server only offline for a moment ??

@matthey
Thanks for your suggestions. I've also thought about a solution with simple shifts and adds like this:
(D1, D2, D3 holding the RGB bytes as longwords)

ADD.L  D2,D1
ADD.L  D3,D1
LSR.L  #2,D1
MOVE.B D1,D2
LSR.B  #2,D2
ADD.B  D2,D1
LSR.B  #2,D2
ADD.B  D2,D1
LSR.B  #1,D2  ; correcting rounding errors here
ADD.B  D2.D1  ; caused by integer devisions with
MOVE.B D1,D2  ; shift instructions losing the
MOVE.B D1,D3  ; remainder, nearly exact now

[Bamiga2002]

Oh I didn't know there was a quota.

[PeterK]

Update to icon.library 46.4.283

Another toy: added the possibility to render grayscale icons. This may look nicer if you use a screenmode with a low number of colors. Try it out. A readme.txt is included in the package.

The new feature "Grayscale Icons"
=================================

1. Copy the command GrayscaleIcons into C:

2. Add a line in your startup-sequence above LoadWB:

GrayscaleIcons

After your system has been booted up to Workbench
you can enable the grayscale icons in Prefs/Workbench
by setting the icon quality to "BAD" like it can be
done for the faster colormapping, too. But both can
not be used at the same time and won't make sense
because the faster colormapping has only 8 grayscales.
The grayscle icons are also disabled when PowerIcons
is active.

Users of Workbench 3.0 or 3.1 also need to add the
FastColors instruction to their startup-sequence
since they can't use Prefs/Workbench for the quality.

@ClarkKent71
Please, tell me if this is what you wanted ?

[mfilos]

New version works just fine Peter mate. Just by putting the command in S-S would suffice for grayscale lovers.

This is what the new version (running GrayscaleIcons) looks like.
It seems it got the beige color from MagicWB palette (as opossed to the previous ONLY grayscale version).

I hope everyone's happy with the thumbnail now...


(I'd have to delete a lot more often my images from the attachement space as the quota is rather limited... which also will delete old posts's images but hey...)

[Retrofan]

Originally Posted by mfilos

(I'd have to delete a lot more often my images from the attachement space as the quota is rather limited... which also will delete old posts's images but hey...)

Yes, I don't understand the Thumbnails. You can't watch them well, so you have to click on them like just a link... but you lose some upload quota.

Isn't just a link to the photo the same (better)?

[PeterK]

Originally Posted by mfilos

This is what the new version (running GrayscaleIcons) looks like.
It seems it got the beige color from MagicWB palette (as opossed to the previous ONLY grayscale version).

I hope everyone's happy with the thumbnail now...
... the attachement space as the quota is rather limited...

If you just change the icon quality settings at runtime then you may also need to "Reset Workbench" from the WB menu in order to remap all colors. Nevertheless, I cannot avoid that the icon color mappings picks up one of the "true" colors as long as that is closer than any of the available grayscale shades.

How do you get this quota problem? Alright, found it in the attachment statistics but I don't see any problem since I'm cleaning up from time to time

@mfilos and Retrofan
It's ok to insert small images into the thread. Let's say up to standard PAL resolution (640*512). And you can still reduce the size by cutting out the section with the most important details. PNG is usually better for screenshots than JPG.

[DH]

And when you eventually use all the quota, like I have 2 or 3 times, deleting the ones that aren't important are a real pain + any images within locked threads you'll need to ask a Global Moderator to delete them for you.

I only use EAB's attachment feature for images that I want to keep, otherwise I use an image hosting site like imgur for things that I don't mind being deleted.

If there's a problem, or the image sizes interfere with thread reading, then use the thumbnail feature in imgur to show the image and add the url link to the thumbnail that'll point to the main image instead.

Like this



Remember, Imgur free is a temperary image hosting site and contains limits to 225 images, where the oldest image will be deleted in favour of the newest, 1MB+ images will be auto compressed to jpg and 6 months of 0 views will auto delete the image/s.

[PeterK]

Thank you DH for pointing out to this alternative solution.

@PeterK
Thank you very much PeterK! This is exactly what I was asking for. Sorry that it took some time for me to reply.

Grayscale-support is working very well, at least for me. It is actually an elegant solution to make all the new icon-formats usable on low-color Amigas, even on an Amiga 3000 without a graphics card. It also gives you the possibility to make the Workbench look retro while still using new icons. Remember that the original Amiga colors (from 1.4 and up) was black/white/blue/gray.

I guess it is a matter of taste but I really like my grayscale + blue palette. I use 15 shades of gray + dark/pale blue. With the PeterK´s library and grayscale support that blue color is not used on icons, the icons look great. I also place the grays in such an order that original and MWB icons also look gray and good by moving the blue color (which is used on active windows) with VisualPrefs and choosing appropriate grays for all MWB colors.

I will post a screenshot one of these days. Again, thanks PeterK.

[matthey]

Originally Posted by PeterK

@matthey
Thanks for your suggestions. I've also thought about a solution with simple shifts and adds like this:

I didn't understand what you were trying to do before but I looked at your .283 source and I see you are simply finding the average of the 3 RGB components. The shift and add division approximation works well for small values like bytes . Your .283 version average result can still be under by up to 3. Adding 2 at the end would make it closer on average (no pun intended) as would using an ADDX after the last shift instruction. I kind of like this though:

(D1, D2, D3 holding zero extended RGB UBYTEs as longwords)

ADD.L  D2,D1   ;add green to red
ADD.L  D3,D1   ;add blue to red
LSR.L  #2,D1   ;start of division d1/3
MOVE.L D1,D2
LSR.L  #2,D2
ADD.L  D2,D1
LSR.L  #2,D2
ADD.L  D2,D1
LSR.L  #1,D2   ;rather than LSR#2+ADDX+ADDQ#1 this approximates
ADD.L  D2,D1   ;end of division d1/3
MOVE.L D1,D2   ;red to green
MOVE.L D1,D3   ;red to blue

It's actually slightly closer on average than what you have now while removing the ADDQ at the end. The result can still be off by up to 2. This should brighten the greys slightly. It would be interesting to see if anyone can see a difference. What would happen if the RGB values were added together and divided by 4 (>>2)? The greys would still be greys but the maximum brightness would just be lowered wouldn't it? How many of the users that want grey are still using a 1084 monitor in interlaced mode to reduce flicker? Darker is better for them anyway .

Notice that I switched to all longword operations. It is up to 2x as fast on the 68060 (and possibly future superscalar processors) to use longword operations where possible. Here is a short optimization guide with some hints:

http://www.freescale.com/files/32bit...80X0OPTAPP.txt

[PeterK]

@ClarkKent71
Thank you for your reply. Good to know that it works for you as it should. Nevertheless, I've made a small modification in the next version of icon.library which will be a new Aminet release. I've noticed a very strange system behaviour coming from the use of the GrayscaleIcons instruction. When that was used then it caused a 10% speedloss even with older icon.libraries. This seems to depend on the tag number which I use in the GrayscaleIcons instruction. It was 0x80009064 which caused the slowdown for unknown reason. I still have to analyse that to find out what goes wrong. But since I've changed the tag number to 0x80009063 (1 less) everything works as normal (no speedloss). And I've also changed the name of the instruction and the way it works. It's new name is GrayscaleOnOff which means that it will toggle between fastcolors and grayscale. So you can also switch back at runtime if you like.

@matthey
I've already changed my code a little as you can see in my older updated posting above. I did that because of the rounding errors coming from the integer divisions which always lose their remainder. Thus, the fourth shift is dividing only by 2 now in order to compensate the rounding errors.

But in your new example you are doing that already with the third shift. Maybe you just left out one shift #2 / add pair accidentally. But dividing by two with the third shift already would cause an overflow error: 191+47+23=261. In my updated example I will get 191+47+11+5=254 and another additional divivion by two would even make the result exact, but wasting too much CPU time.

Is a long shift or add the same number of CPU cycles on an 68020 as using bytes only ??

[matthey]

Originally Posted by PeterK

@matthey
I've already changed my code a little as you can see in my older updated posting above. I did that because of the rounding errors coming from the integer divisions which always lose their remainder. Thus, the fourth shift is dividing only by 2 now in order to compensate the rounding errors.

The round bit from LSR is shifted into the CCR[X] bit but using an ADDX instead of ADD on each iteration still didn't fix the rounding inaccuracy .

Originally Posted by PeterK

But in your new example you are doing that already with the third shift. Maybe you just left out one shift #2 / add pair accidentally. But dividing by two with the third shift already would cause an overflow error: 191+47+23=261. In my updated example I will get 191+47+11+5=254 and another additional divivion by two would even make the result exact, but wasting too much CPU time.

You are correct. My original code above would have only worked for a UBYTE (with an accuracy of +-2) but after summing up the RGB vaues (255+255+255=765 max) another iteration is necessary with a shift by 1 at the end giving a good approximation again. The result is also +-2 and closer than the .283 code. I corrected the code in my last post rather than lengthening this one.

Originally Posted by PeterK

Is a long shift or add the same number of CPU cycles on an 68020 as using bytes only ??

Yes. Most 68020+ operations are the same number of cycles as a longword except for multiply and divide. Longwords are faster on the 68020 sometimes also. Using (d8,An,Xn.w) instead of (d8,An,Xn.l) requires an extra operation to sign extend the scale register. The 68060 needs to recombine a byte or word result into the old destination register but it's simpler to update the whole register. MULU.W and DIVU.W have a longword (whole register) result even though they are word operation so they are not a problem. It's better to use longword inputs (sign or zero in upper words) for them. That guide I linked has some good examples and tips at the top. It's possible to produce mostly optimal code from 1 assembler source for the 32 bit 68020-68060 in most cases (not so with the 16 bit 68000).

[PeterK]

but using an ADDX instead of ADD on each iteration still didn't fix the rounding inaccuracy .

Because this would only set D1 correct but it won't add the X bit to D2 also.

I made a mistake too. In order to get the exact result it would, of course, need another division by 4 and not by 2 as I said before.

Thanks a lot for your optimization suggestions, I will use longword operations now

So, the best solution would be your previous code and an ADDX.L instead of the final ADD.L.

[matthey]

Originally Posted by PeterK

I made a mistake too. In order to get the exact result it would, of course, need another division by 4 and not by 2 as I said before.

It should work to do 2 shifts at a time because the binary decimal repeats every 2 bits. It's just a little slower if 4 shifts is possible with the algebraically simplified version of the equation and the number being divided is big enough to need it.

Originally Posted by PeterK

So, the best solution would be your previous code and an ADDX.L instead of the final ADD.L.

I wouldn't use the shift by 1 at the end and the ADDX. The code above approximates a little high and ADDX makes it worse (higher yet). Using the simplified version of the equation with ADDX gives a +-2 result as well:

ADD.L  D2,D1   ;add green to red
ADD.L  D3,D1   ;add blue to red
LSR.L  #2,D1   ;start of division d1/3
MOVE.L D1,D2
LSR.L  #2,D2
ADD.L  D2,D1
MOVE.L D1,D2
LSR.L  #4,D1
ADDX.L D2,D1  ;end of division d1/3
MOVE.L D1,D2   ;red to green
MOVE.L D1,D3   ;red to blue

Edit: This code is a little smaller and faster on the 68020-68040 (about even on 68060) but the 1st code is more accurate on average even though the max error is +-2 for both. It's up to you or do better .

[PeterK]

@matthey
Hmm, what should I say now?
Perfect solution for this job !
Well done, thanks matt