using gmic 256,256,256,3,[x,y,z] -o all_colors.cube and converting it to PNG like this:
but if i do the same with gmic 128,128,128,3,[x,y,z] -o all_colors.cube converted to PNG:
what’s wrong here? i thought there should be not a big difference above 48x48x48 since that’s what everyone on the internet been telling me for a week now
the first PNG file is too big so here’s a screenshot of the first few colors:
and here’s a screenshot of the 2nd PNG first few colors (same sorting):
In that case, your color values will be in range [ 0,127 ], not [0,255], so the resulting overall image will look half darker indeed.
If you want to keep the value range [0,255] but with 128x128x128 cubes, then:
$ gmic 128,128,128,3,"[lerp(0,255,x/(w-1)),lerp(0,255,y/(h-1)),lerp(0,255,z/(d-1))]" -o output_colors.cube
But of course, you won’t get all the 16777216 possible colors in that case.
EDIT: the expression below will be valid also for other values than 128.
oh this is interesting… but it doesn’t seem to affect the dimmed tiles by default sorting when using:
gmic 256,256,256,3,“[lerp(0,255,x/(w-1)),lerp(0,255,y/(h-1)),lerp(0,255,z/(d-1))]” -split_tiles -128,-128 -split z -append_tiles , -o colors.png
I also tried different sorting methods from what i could understand from the commands list it keeps giving those first few dimmed colors for some reason
Then probably this could be interesting :
$ gmic 128,128,128,3,[x,y,z] n 0,255 -split z -append_tiles ,
But of course, as 128 is not a square number, you cannot rearrange all the 128x128 tiles in a square image (that explains the black part at the bottom right).
EDIT: You can do it with 64x64 tiles though, because 64 is a square number.
For 128x128 blocks, it is possible to arrange the image into 16x8 blocks though:
$ gmic 128,128,128,3,[x,y,z] n. 0,255 s z append_tiles 16 o all128.png
sorry i meant when doing it at 256^3
gmic 256,256,256,3,"[lerp(0,255,x/(w-1)),lerp(0,255,y/(h-1)),lerp(0,255,z/(d-1))]" -split_tiles -128,-128 -split z -append_tiles , -o colors.png
also with n 0,255 it still gives the dimmed tiles for doing this weird color sorting by default :
OK I see.
The dimming here can be explained by the fact your 256x256x256 cube is divided into 4 sub-cubes, the first one being the one containing the most darker colors.
You can modify how it is sorted, for instance by splitting into 128x128 after the decomposition along the z axis:
$ gmic 256,256,256,3,[x,y,z] s z split -128,-128 append_tiles , o colors.png
In this case, this is actually equivalent to having 256x128 blocks.
yeah that’s the closest i could get yesterday and i almost gave up i’m still trying to find a way to get the 16m RGB colors sorted the normal way inside 128x128 blocks and by using -append_tiles 128 to get the max width supported by the APIs
someone did it here inside smaller blocks of 16x16
i think g’mic might be missing a specific color sorting function for this and for other color distribution methods as well
The fact is I don’t really understand what you are expecting exactly.
What is the sorting criterion you are looking for?
i’m expecting the colors to be sorted inside the blocks the same way they are sorted when we are not using -split_tiles for simply smaller blocks and we don’t specify any sorting methods so the default criterion is changing after -split_tiles i guess idk i’m still very new to this
gmic 256,256,256,3,[x,y,z] -split_tiles -16,-16 -split z -append_tiles , -o colors.png
should give the same colors of:
gmic 256,256,256,3,[x,y,z] -split_tiles -256,-256 -split z -append_tiles , -o colors.png
only difference is the blocks are smaller at 16x16 instead of 256x256 so the output should be almost identical to this:
Hmm, I am having a idea here. I can adapt the rep_cartesian_product into doing those things. Have a play with it, it generates all possible coordinates for any dimensions and sizes up to what your memory can store. And you can find offset position by using rep_cartesian_product_index2list.
i don’t think it’s a dimension issue it should be the coloring method like the RGB distribution by hue, gamma, etc i don’t really know anything about this
gmic 256,256,256,3,[x,y,z] -split_tiles -256,-256 -split z -append_tiles 128, -o colors2.png
gmic 256,256,256,3,[x,y,z] -split_tiles -128,-128 -split z -append_tiles 128, -o colors.png
i can see and conclude a totally different color sorting criterion between the 2 outputs when we could do the same color output inside smaller blocks
