NEW CLUSTER STUDY THREAD!

[Ai]

I was surprised that "Level mode (stretched, clipped)" did not effect the result of Bits per channel -- because basically all clipped colorspaces defined by existing systems are expressible in bits per channel. I realize that you could say 'well, use levels instead for that' (once levels is implemented), but IMO it is less surprising if that particular option applies universally.  Maybe instead of 'level mode' you could call the option 'intensity mapping'.

... Or you could automatically sync the bits / levels fields where possible (eg bits is set to 3 when user inputs levels . That would be simpler and more functional maybe.


(.. and I just now realized that Level mode was supposed to specifically be a part of the Levels section. That's a formatting issue -- My quick-and-dirty html skills would probably have stuck it in a blockquote to clarify its subordinateness)

[ptoing]

Ai: Hm, the 3D cube looks like CPC colours and the small cube does not. Are they supposed to be the same? Is there some weird colou profile active on the small png?

[RAV]

I worked a lot in 555 for GBA and DS stuff, and I never felt like that was a limitation at all.

I agree. 555 might as well be 24bit, as far as pixel artistry goes.

As a funny anecdote:
My old Afterlife demo basically represents all of 555 colour space to explore, that is 32x32x32 rgb-cubes. (the whole scene is 64x64x64, but that is just symmetric repetition.)
I've still kept this as a mode in the new to collect a palette. The space can switch between representing 111 - 555, and it just hasn't seemed necessary to go further, though it could.
This is just an optional helper map-mode for starters though. Once picked, colours can still be fine-tuned in full 256 steps by their standard rgb-bars.

[Ai]

Ai: Hm, the 3D cube looks like CPC colours and the small cube does not. Are they supposed to be the same? Is there some weird colou profile active on the small png?

Hmm? I don't think I have posted a CPC cube in this thread. The only 3x3x3 I posted was the YCbCr cube in my recent post, which AFAIK isn't a master palette used by any real system.
Unless by 'small cube' you are referring to the content of the large 3d cube image I posted in the OT thread -- there are three or four levels of compositing there and I didn't quantize the result back to CPC colordepth.

Looking at the stuff I did when messing around with colorcubes, if you want an adjusted CPC colorcube there is this (less extreme saturation, each color is more distinct). I hadn't linked it here before.

[surt]

Updated: http://img.uninhabitant.com/colourcube.html
Implemented custom levels and intensity mapping (I like that) options.
Auto update not implemented yet.

I was surprised that "Level mode (stretched, clipped)" did not effect the result of Bits per channel

I'm not sure what you mean. They only effect how the number of levels (which can be calculated from a bit depth) are evaluated at 8-bit per channel.

(.. and I just now realized that Level mode was supposed to specifically be a part of the Levels section. That's a formatting issue -- My quick-and-dirty html skills would probably have stuck it in a blockquote to clarify its subordinateness)

Hopefully the current formatting is clearer.

[ptoing]

Levels per channel seems to be quite fucked if you do weird numbers, like 2, 3, 255. The output makes no sense at all.
Also you should be a able to have 256 steps not just 255. 0-255 = 256 steps.

[Ai]

EDIT2: BTW surt, this report is still accurate after your posted fix for ptoing's error below.

I think I found a bug -- entered 3 in the middle field, left others at 2. In the link, you can see that the result is clipped.. and also there don't appear to be 2**3 == 8 distinct Green levels, rather, there are still 4 distinct levels and they are used .. improperly? Well, the result doesn't quite make sense when you look at it, that's for sure.

testing some other values:

2, 3, 3 looks correct
2, 2, 3 does not
3, 2, 2 looks correct
1, 2, 3 does not
3, 2, 1 does not
3, 1, 2 does not
2, 3, 1 does not (wow, very not)
2, 1, 3 does not

I've looked over the code, but nothing jumped out at me as being wrong in a way that would cause this effect.
(also, your code has caused my opinion of JavaScript to rise. Doing that in that little code? It ain't NumPy, but it's pretty good.)

FWIW, the levels readout always appears correct, so those arrays must be populated correctly. The image metrics also seem to be correct (although I haven't tried with super corner cases like ptoing).. So I guess that the bug is about the arrays being indexed incorrectly.

I'm not sure what you mean. They only effect how the number of levels (which can be calculated from a bit depth) are evaluated at 8-bit per channel.

Well, to my mind, bits per channel is a compact way of specifying levels per channel --  2 means 2**2 == 4 levels, 4 means 2**4 == 16 levels, etc. Which is why it made sense to me that the setting for how these N intensities were mapped to the 0..255 continuum would be shared between them -- bpc is just a different notation for entering number of levels.

Yes, the current formatting is an improvement.
The Levels readout to help easily tweaking custom levels is helpful, too.

[surt]

Levels per channel seems to be quite fucked if you do weird numbers, like 2, 3, 255. The output makes no sense at all.
Also you should be a able to have 256 steps not just 255. 0-255 = 256 steps.

Whoops, yes.
Fixed the level count. Though with all 256 and swatch size bigger than 1 will probably produce an image too big for the browser to handle.
I had the green and blue levels mixed up so if they were different it'd be gibberish. Fixed now.
Still something wrong with BGR.

[Ai]

Whoops, yes.
Fixed the level count. Though with all 256 and swatch size bigger than 1 will probably produce an image too big for the browser to handle.
I had the green and blue levels mixed up so if they were different it'd be gibberish. Fixed now.
Still something wrong with BGR.

Just did some more testing. The cases I report above are still bugged, for BPC mode, and Levels per channel still seems to have a bug -- eg levels (2,3,4) == wrong(only 3 levels of B are used, the fourth tile uses #0 again)

EDIT: can reproduce on both firefox and midori.

[ptoing]

rgb443 is also totally fucked. You are doing something weirdly. Actually in the build that is up atm everything but cases where all numbers are the same fuck up in some way. You must have some bug in the way you draw in the values.

Edit: Werks now. Good jerb.