RSS/Atom feed Twitter
Site is read-only, email is disabled
  1. Chat
  2. Useful links
  3. Polls

Featured content

High bit depth assets to GIMP 2.10

This discussion is connected to the gimp-developer-list.gnome.org mailing list which is provided by the GIMP developers and not related to gimpusers.com.

This is a read-only list on gimpusers.com so this discussion thread is read-only, too.

4 of 4 messages available
Toggle history

Please log in to manage your subscriptions.
High bit depth assets to GIMP 2.10 Americo Gobbo 23 Oct 00:50
  High bit depth assets to GIMP 2.10 Americo Gobbo 23 Oct 00:57
  High bit depth assets to GIMP 2.10 Elle Stone 23 Oct 13:57
   High bit depth assets to GIMP 2.10 Elle Stone 23 Oct 14:11
Americo Gobbo
2016-10-23 00:50:54 UTC (about 8 years ago)

High bit depth assets to GIMP 2.10

Hi All,
Is possible discuss again the possibility to have assets in 16 and 32 bit, mainly the palettes and patterns. The initial discussion was proposed by Alexandre Prokoudine, in 2014 > https://mail.gnome.org/archives/gimp-developer-list/2014-February/msg00050.html Thanks,
americo

Americo Gobbo
2016-10-23 00:57:31 UTC (about 8 years ago)

High bit depth assets to GIMP 2.10

On 22-10-2016 22:50, Americo Gobbo wrote:

Is possible discuss again the possibility to have assets in 16 and 32 bit, mainly the palettes and patterns.

A short and important addendum.... the gradients, too.

gimp-developer-list mailing list
List address:gimp-developer-list@gnome.org
List membership:https://mail.gnome.org/mailman/listinfo/gimp-developer-list
List archives:https://mail.gnome.org/archives/gimp-developer-list
Elle Stone
2016-10-23 13:57:06 UTC (about 8 years ago)

High bit depth assets to GIMP 2.10

On 10/22/2016 08:50 PM, Americo Gobbo wrote:

Hi All,
Is possible discuss again the possibility to have assets in 16 and 32 bit, mainly the palettes and patterns. The initial discussion was proposed by Alexandre Prokoudine, in 2014 > https://mail.gnome.org/archives/gimp-developer-list/2014-February/msg00050.html

That's an interesting discussion. Here's a link to the Nabble archive (makes it easier to read the entire thread):

http://gimp.1065349.n5.nabble.com/assets-in-the-high-bith-depth-age-td41929.html

I would very much like to see palettes and such stored using 32f floating point LCH rather than 8-bit RGB, for two reasons:

1. Eight-bit precision is insufficient precision for storing linear gamma color information - darker colors are severely posterized upon being saved to disk, to the point where the human eye can see that the color has changed.

2. LCH is independent of the RGB color space, which means "color managing" the LCH assets is a matter of converting from the stored LCH values to whatever RGB working space the user happens to be using. Which for GIMP 2.10 really should be sRGB, but as indicated by the Roadmap for future versions of babl/GEGL/GIMP this will change.

Has Krita moved on past the 8-bit assets? If so what is Krita using to store palettes and such?

16-bit integer would be enough to store "more precision than the eye can see", but wouldn't allow to store colors that are outside the display range, whereas high bit depth GIMP's (rather babl's, with supporting unclamped operations in GEGL and GIMP) RGB/XYZ/LAB/LCH color conversions do allow to calculate and store out-of-display-range colors.

Elle

Elle Stone
2016-10-23 14:11:21 UTC (about 8 years ago)

High bit depth assets to GIMP 2.10

On 10/23/2016 09:57 AM, Elle Stone wrote:

On 10/22/2016 08:50 PM, Americo Gobbo wrote:

Hi All,
Is possible discuss again the possibility to have assets in 16 and 32 bit, mainly the palettes and patterns.

On the topic of high bit depth assets, it would also be nice if the color sliders for picking colors would read out high bit depth values, either always floating point, or else as appropriate to the bit depth of the image.

Eigh-bit integer color sliders for picking colors just isn't enough precision for working with high bit depth images.

Twice I've tried to modify the relevant code, but failed because I couldn't figure out how to get past the part of the code that seems to use the size of the box to relate slider movements to the RGB values. All the relevant code uses guchar variables.

Elle