@Karlos

Quote:

So, as I mentioned above somewhere, I experimented with YUV HAM in MC64K before just going with RGB again. The problem with YUV is that it's just not a remotely intuitive format for software colour manipulation. It might not matter if all you are doing is manipulating prerendered graphical elements on a buffer.

HAM isn't an easy format for colour manipulation either, so I don't think we lose anything.

Quote:

It was also apparent in my 5-bit version (not HAM in general) that you need greater resolution for the luminance than your desired but depth can deliver.

How bad did it look? You could use HAM8, or just accept the limitations (as you have to with HAM mode, no matter how you use it).


Quote:

They were both a part of the history, really. The demise of AGA marked the end of an era. The demise of PPC marks the end of an error.

A few days ago, I stumbled on someone claiming that AGA Amigas weren't real Amiga computers either. To him, only OCS and ECS were the real deal.

So many personal definitions of what is and isn't an Amiga computer...

Hans

Last edited by Hans on 06-Feb-2024 at 06:26 AM.

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@cdimauro

Quote:

Quote: Yes, the base palette isn't the same as the actual pixel colour, but the average colour error is going to be a good step less than just pasting a bob on top and doing nothing (and the maximum error is greatly reduced). I can't comment on how visually annoying the remaining error would be, because I never got round to testing it out. Maybe someone can take the chance and give a try. There are plenty of "old style coders (!)" which could find it fun.

I hope someone does, because I'd be curious as to what results you could get.

Quote:

Anyway, your method requires double the space (as you already stated) and double cookie-cut of the BOB (since you don't know where the right border of the BOB ends).

Not quite, but close. You'd start with 7 bitplanes (6 for colour, and 1 mask), and then add another 5 (4 bit-planes for the base-palette version, plus the right-edge mask).

Yes, the 2MiB chip-ram is going to feel a bit small...

Quote:

Quote: Thinking about it a bit more, you could write a HAM dithering algorithm to generate HAM images with a rule that every colour channel must be covered at least every n pixels (n being yet another trade-off, smaller means less fringing, but more noise in the original image). Hum. Do you mean that if n == 3 then in 3 subsequent pixels each colour component should have been changed?

Yes, either by a base palette colour, or by individual channels. Most likely, you'd choose a larger n, though, or the image noise will probably be rather high.

Quote:

Quote: Haha. I haven't forgotten the horrible flickering. However, interlaced TVs didn't flicker horribly due to proper antialiasing. I don't recommend it anyway. I had my A1200 attached to a 16" TV of the time, and interlace was really horrible to sustain for long time.

The TV doesn't do anti-aliasing; it's part of the input signal. Decades ago I stumbled on a software only flicker-fixer for the Amiga. I can't remember what it was called, but I do remember that it basically did some kind of anti-aliasing between scan-lines. This really did wonders to that annoying flicker.

Quote:

I know the Graffiti. Yes, it could be implemented that way, but only in LORES (using HRES as the "master") or HRES (using SHRES as "master").

I was referring only to the way that the Graffiti plugged into the RGB port externally. YUV=>RGB conversion could be done at the screen's native resolution. Unlike the Graffiti card we're not trying to add extra colour information per pixel beyond what HAM mode provides.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

Quote:

HAM isn't an easy format for colour manipulation either, so I don't think we lose anything.

This is true but you have to remember you are dealing with an intersection of problems now. HAM is fiddly sure, but at least RGB colourspace calculations for things like mixing and brightness and saturation are pretty intuitive and well understood. You can even approximate both the latter operations as a mix with 0,0,0 or mix with 1,1,1 (normalised scale). The only gotcha is the fact that gun brightness isn't linear, it's effectively proportional to x^0.5, so to get good blending you square your channel values before summing, taking the root and then dividing.

Now, while I appreciate that brightness and saturation are now just direct values you can edit in YUV but calculating how to blend a pair of colour values - especially if they are in RGB to begin with, is much more involved. The line of colours through YUV space where the saturation and value are 1.0 is probably not very well quantized into an integer value for your chroma channel, either.

Quote:

How bad did it look? You could use HAM8, or just accept the limitations (as you have to with HAM mode, no matter how you use it).

Not great, tbh. The reason I was going for 5 bit though is because I had a control bit for each channel, so in a single chunky byte pixel you can have either a palette entry (32 from RGB15), or modify any combination of the R G B values at once (5 bit precision).

_________________
Doing stupid things for fun...

@Karlos

Quote:

This is true but you have to remember you are dealing with an intersection of problems now. HAM is fiddly sure, but at least RGB colourspace calculations for things like mixing and brightness and saturation are pretty intuitive and well understood. You can even approximate both the latter operations as a mix with 0,0,0 or mix with 1,1,1 (normalised scale). The only gotcha is the fact that gun brightness isn't linear, it's effectively proportional to x^0.5, so to get good blending you square your channel values before summing, taking the root and then dividing. Now, while I appreciate that brightness and saturation are now just direct values you can edit in YUV but calculating how to blend a pair of colour values - especially if they are in RGB to begin with, is much more involved. The line of colours through YUV space where the saturation and value are 1.0 is probably not very well quantized into an integer value for your chroma channel, either.

I'm looking at this from the perspective of trying to get more colours on-screen for typical classic Amiga games using the HAM mode. They typically work almost entirely with predrawn imagery. In that context, converting everything to YUV isn't a problem because it's all calculated ahead of time.

Planar screen modes are unsuitable for real-time colour manipulation beyond changing the screen's colour palette (which won't work properly with HAM). So, if that's what you want to do, then planar modes of any type are unsuitable. Forget HAM and anything classic Amiga chipset, and switch to chunky pixels.

Hans

_________________
http://hdrlab.org.nz/ - Amiga OS 4 projects, programming articles and more. Home of the RadeonHD driver for Amiga OS 4.x project.
https://keasigmadelta.com/ - More of my work.

@Hans

If it's all predrawn, I don't see any problem. Well, perhaps the one problem that 64 might not have enough resolution for chroma selection, but since our eyes are not particularly as bothered by that as they are brightness, it may not matter.

Going back though, a place where this would really work well, is what Jay originally intended - shaded polygons. You scan out your horizontal line, modulating the brightness of some starting colour for the basic lighting and modulate saturation (i.e. drive towards white) for any specular component.

Your basic 32-colour flat polygon engine now looks awesome with smooth Gouraud / shading and specular highighting, without the cost that normally comes with in RGB space.

Last edited by Karlos on 06-Feb-2024 at 12:54 PM.

_________________
Doing stupid things for fun...

@Hans

Quote:

Hans wrote: @cdimauro Quote: Maybe someone can take the chance and give a try. There are plenty of "old style coders (!)" which could find it fun. I hope someone does, because I'd be curious as to what results you could get.

Worst case using Python + PyGame should be easy to emulate HAM and moving such particular BOB to see what's happening.
Quote:

Quote: Hum. Do you mean that if n == 3 then in 3 subsequent pixels each colour component should have been changed? Yes, either by a base palette colour, or by individual channels. Most likely, you'd choose a larger n, though, or the image noise will probably be rather high.

Indeed. n == 3 is too strict, and fulfilling it will create other artifacts.
Quote:

Quote: I don't recommend it anyway. I had my A1200 attached to a 16" TV of the time, and interlace was really horrible to sustain for long time. The TV doesn't do anti-aliasing; it's part of the input signal. Decades ago I stumbled on a software only flicker-fixer for the Amiga. I can't remember what it was called, but I do remember that it basically did some kind of anti-aliasing between scan-lines. This really did wonders to that annoying flicker.

Never heard of something like that. But now it's too late to try it.
Quote:

Quote: I know the Graffiti. Yes, it could be implemented that way, but only in LORES (using HRES as the "master") or HRES (using SHRES as "master"). I was referring only to the way that the Graffiti plugged into the RGB port externally. YUV=>RGB conversion could be done at the screen's native resolution. Unlike the Graffiti card we're not trying to add extra colour information per pixel beyond what HAM mode provides. Hans

AFAIK Graffiti uses a 16 colours HRES mode to simulate a 256 colours LORES mode, because there's no other possibility by reusing what the Amiga OCS/ECS allowed.

The circuit in the box sampled the 16 possible colours of each HRES pixel and paired two of them at the time to build the 8 bit value which it then uses as an entry on the CLUT (which was sent to the box during the VBLANK, via some special commands).

@Hans

Quote:

Decades ago I stumbled on a software only flicker-fixer for the Amiga. I can't remember what it was called, but I do remember that it basically did some kind of anti-aliasing between scan-lines. This really did wonders to that annoying flicker.

MagicTV: https://aminet.net/package/util/wb/magictv2

I used to use that on a 1084 before I went RTG. It was pretty effective.

_________________
Doing stupid things for fun...

Would it have been possible to make a HAM mode that altered the Hue, Saturation, or Luminance ie. 00-Palette Colour, 01-Change Hue to, 02-Change Saturation to, 03-Change Luminance to...

I feel like if that were able to be implemented that it would almost allow the elimination of visible artifacting?

Would it have been possible to create the circuitry to change the H|S|L rather than just change the red, green, or blue?

@Hans

Quote:

Hans wrote: A few days ago, I stumbled on someone claiming that AGA Amigas weren't real Amiga computers either. To him, only OCS and ECS were the real deal. So many personal definitions of what is and isn't an Amiga computer... Hans

The original NTSC A1000 didn't have 6-bitplanes 64-color EHB mode. Later NTSC and PAL A1000 have 64-color EHB mode.

C= Amiga has established color display improvements since A1000. The problem is Amiga's color display evolution has stalled until AGA's release.

_________________
Ryzen 9 7900X, DDR5-6000 64 GB RAM, GeForce RTX 4080 16 GB
Amiga 1200 (Rev 1D1, KS 3.2, PiStorm32lite/RPi 4B 4GB/Emu68)
Amiga 500 (Rev 6A, KS 3.2, PiStorm/RPi 3a/Emu68)

@gonegahgah

Try it. All you need to do is to write something that can covert an image in your hypothetical HAM format into RGB so that you can assess the results. No hardware necessary.

_________________
Doing stupid things for fun...

@gonegahgah

Quote:

gonegahgah wrote: Would it have been possible to make a HAM mode that altered the Hue, Saturation, or Luminance ie. 00-Palette Colour, 01-Change Hue to, 02-Change Saturation to, 03-Change Luminance to... I feel like if that were able to be implemented that it would almost allow the elimination of visible artifacting?

HSL improves the situation compared to RGB, but fringing is here to clearly stay.

@cdimauro

Can it be helped with an isotonic palette dropping saturation and dynamic range to the source?

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

Quote:

number6 wrote: @cdimauro Can it be helped with an isotonic palette dropping saturation and dynamic range to the source? #6

Sorry, I don't get it. Could you please provide an example?

@cdimauro

Granted this is 256 color mode example I made to circumvent WB palette picking, but better imagery came from this weird looking palette imo.

example image

So I just wondered if you did something similar to a ham palette could you eliminate fringing a bit?

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

Quote:

number6 wrote: @cdimauro Granted this is 256 color mode example I made to circumvent WB palette picking, but better imagery came from this weird looking palette imo. example image So I just wondered if you did something similar to a ham palette could you eliminate fringing a bit? #6

Unfortunately you can't do the same.

That's because HAM has only 16 base colours and all other are derived by changing a component at the time.

Unless you want to use just those 16 colours.

@cdimauro

Understood. Hence also why I thought dropping saturation and shrinking dynamic range on the source might help. Transition to the human eye might be smoother.

Based on:

Quote:

We know that human eye is not sensitive to color patterns in high frequencies; therefore we use luminance patterns because the eye is more sensitive to luminance patterns in high frequencies and is able to distinguish the edges.

In other words since there are only "16" stick to the range most sensitive to the human eye.

#6

_________________
This posting, in its entirety, represents solely the perspective of the author.
*Secrecy has served us so well*

@number6

If is a RGBRGBRGBRGBRGBRGB pattern. the distortion is only 2 pixels wide, with higher resolution, the distortion is decreased even more. but to make this work everything has to use this pixel pattern. Or else you get this ugly long distortion lines. The problem is that DPaint does not produce pictures like that.

if you picture generated for image quality, you have different pattern.
RRRRGGGBBRRRGBBRRRR, etc, if the changes in the only based on delta value of R,G,B channels, you change channel with highest error delta first. Then of course you sprinkle the picture with solid colors, that has closes match, perhaps find parts of the picture that has the worst match find the colors, find color count, sort it, and sprinkle solid colors there, if the solid color has lower error.

_________________
http://lifeofliveforit.blogspot.no/
Facebook::LiveForIt Software for AmigaOS

@number6

Quote:

number6 wrote: @cdimauro Understood. Hence also why I thought dropping saturation and shrinking dynamic range on the source might help. Transition to the human eye might be smoother.

Which happens by using another colour space like HSL, YUB, LAB, etc., where luminance has a proper channel, but this cannot remove the fringing which is part of HAM's intrinsic nature.
Quote:

Based on: Quote: We know that human eye is not sensitive to color patterns in high frequencies; therefore we use luminance patterns because the eye is more sensitive to luminance patterns in high frequencies and is able to distinguish the edges. In other words since there are only "16" stick to the range most sensitive to the human eye. #6

Yes, got it. However the problem here is that you've to carefully chose those 16 colours to "cover" as much as possible all pixels of the image by reducing all components transistions.

Basically you're not free to chose whatever you want for those colours.

I mean: you can, as per your proposal, because you (the image creator) are the one that can select them one by one, but the end result wouldn't be optimal and you'll see several other artifacts.

@Hans

Quote:

A few days ago, I stumbled on someone claiming that AGA Amigas weren't real Amiga computers either. To him, only OCS and ECS were the real deal.

Yeah and I guess you have to use cracked software loading from a floppy to get the 'true' Amiga experience?! Some people!! I would hazard a guess they jumped ship to a PeeCee as soon as they could afford one yet they begrudge the Amiga developing beyond the A500!

_________________
"Art challenges technology. Technology inspires the art."
John Lasseter, Co-Founder of Pixar Animation Studios