When an image is created a bit depth can be selected. I have a request in that regard and that is we have 8 bits and 16 bits, I want 10 bits (to match the 30bit displays/1.07 billion colors). That is my primary request here I consider that an important feature (we don't know when 30 bit displays, that is 1 billion color displays will become popular on the mass market, although they already are in some professional markets)

However besides that request, I would like this menu to be relabeled to more correctly emphasize what it means, "Bits Per Channel(Depth)" and the entries to be changed from

8 Bit
10 Bit
16 Bit
...

to

8 Bpc (24/32 Bits)
10 Bpc (30/40 Bits)
16 Bpc (48/64 Bits)

This is because the value in this configuration/setting is actually not Bit Depth but Bits Per Channel (and if you have nvidia proprietary drivers on linux installed, you will see that they use the term BPC too, so I didn't exactly just come up with it myself)

For Krita's users (old and new) I think this would both prevent confusion, and educate them a little about a slightly obfuscated technical term.

Also to reflect on the more detailed name of the labeling of this setting, I would like to also suggest changing it's nearby entries from

Model
Profile

to

Color Model
Color Profile

for further clarification of them as well. And while at it, in the above configurations, change "Resolution ->number<- ppi" to "Pixels Per Inch ->number<-" because resolution (although correct term) is confusing when it is synonymous for display resolution which is to the left of this configuration. But resolution doesn't need to be removed entirely, just moved.

Where it says "Image Size" consider making it say "Image Resolution" instead. Apart from the 30 bit depth support request, all the things I requested may be details (or semantics) but details matter and besides, I imagine this wouldn't be so hard to change. What I basically want is the labeling of options available in custom document creation to be more precise/accurate to effectively prevent misunderstanding and hopefully increase users understanding of how the technical aspects of digital images work, rather than mystifying it.

What do you guys think?

PS: I noticed a bug that if I change the bit depth, the color profile gets reset to sRGB, this is less than desirable, especially since people might fail to notice it when they mess with this.

Why is 10BPC important to you? I don't think any file formats support it (except .raw, but that's mostly meant for camera imports), and you can always just use the more widely-supported 16 bit (which will display correctly on your 10, 12 or 15-BPC screen)

The rest of the suggestions sound good to me; maybe make bugreports for them.

oh yeah you're right, I didn't realize that neither PNG nor JPG support 10 bpc. I would've thought they would since they support 48 bit.

Honestly I think 48 bit is overkill considering it supports like what 281 trillion colors? I imagine it takes a lot more processing power (not to mention the filesizes are like roughly 340% the size of 24 bit equivalents) I notice that Krita at least slows down a bit if I work under 16 bpc. I figured 30 bit with 10bpc and only 1 billion colors would be a lot more efficient to say the least. I guess for now though I might just rather hope that it becomes a standard soon. 12 bit JPG exists, but I don't like the JPG format to begin with because it's lossy (sorta ruins the whole point doesn't it? ) and ask for this feature again when PNG or a comparable format supports it (I wonder though if bitmap embedded in SVG supports it)

Your standard desktop CPU isn't faster with 10 bit and I guess even slower. The current 8, 16 and 32 bit values direct map onto the hardware, while 10 bit would have to emulated. Beside that no major fileformat uses 10 bit.

I don't think we need another description for the bit depth. I have to look twice to see what "8 Bpc (24/32 Bits)" means. Beside that we go up to 32 bit which would be "32 Bpc (96/128 Bits)" and that looks totally strange. The users doesn't have to know that information at all and it's even more confusing than the current one. It's industry standard to only use the depth of one channel.

The "color" is already in the title on the box. The other "color" would just be redundant.

"Image Size" and "Image Resolution" are two different things.

Yeah, for practical purposes 48/64 bpp (aka 16bpc) is probably overkill (not to speak about 32bpc, or 128bpp for an RGBA image!) but as things stand right now (at least in my experience) most people either only use 8bpc images (applications where size is an issue; web-images; etc -- these mostly don't really have much use for higher depth images -- browsers etc aren't even currently capable of displaying them, AFAIK) or higher bpc counts, but then either size doesn't matter that much (photography) and/or special image-formats/care is taken (e.g. special texture compression formats for HDR cubemaps or images as used in videogames, rendering, image-based lighting and such.)

I think for your average image-needs it's fine to draw at 16bpc (or 8, if you don't need the higher dynamic range) and then store at 8bpc or 16bpc, if you really don't want to lose the higher dynamic range.

w.r.t. efficiency, krita would probably not be able to get much of a performance benefit from using 10 bits over 16 bits (if at all) -- CPUs don't typically support 10-bit or multiple-of-10-bit datatypes natively, so all CPU-side computations would probably have to happen at 16-bit precision anyway. GPUs can use 10-bit textures (e.g. through ARB_texture_rgb10_a2ui) but I have no idea whether that's generally faster or more power-efficient than using 16-bit ones. There is only a chance that for any given GPU this will give any kind of performance benefit, depending on whether the driver/GPU just converts it to a 16-bit texture at some point (e.g. before the texture upload.) There is also no guarantee that any given GPU supports 10-bpc textures, it's an optional feature. This is purely speculation though, I'm not a krita dev.

Filesize is of course an argument, but I don't know where you have 340% from -- using 10bpc over 16bpc should save you something like ~30% or so, and conversely your 16bpc image should be about ~160% as big as a 10bpc one. But that's not all that great of a win in the end if it means you have to spend a lot of CPU power when the image is being loaded to convert it to a 16bpc one, or whatnot. When the image is compressed (whether lossy or lossless) this difference between 10bpc and 16bpc will probably become even smaller (compression should be good at removing unused dynamic range.)

SVG just embeds JPG or PNG, so it could only support it if one of those supports it (but maybe it wouldn't, even then; I'm not sure if the SVG standard makes any requirements as to what kind of color-depth is supported. So it's probably up to the SVG viewer to do whatever it wants)

What did I say? 10 Bit displays are becoming a thing now. About half of the 4K monitors I saw pumped out over the last few months are 10-bit instead of 8-bit.

But well, I guess there's still little we can do about file formats not supporting that bit depth yet. (Although I suspect the new BPG does, it's HEVC based, and HEVC supports 10-bit video encoding...)

HEVC is also very heavily patented (as is most of the other stuff around wavelets), so it seems unlikely that anybody is ever going to use BPG.

Also, it's still not lossless, so PNG is kinda still better if you can afford the increased filesize...