07-21-2025, 09:14 PM
(07-21-2025, 05:40 PM)teapot Wrote: Thanks Ofnuts,
Working though your example to see if I understand the figures:
Colour selector: #ff8040
Code:
255/255 = 1.0
128/255 = 0.50196078431372549019
64/255 = 0.25098039215686274509
Converting from perceptual to linear using
https://en.wikipedia.org/wiki/SRGB#Trans...amma%22%29
gives results close to yours:
Code:
➤> def g(v): return ((v + 0.055) / 1.055) ** 2.4
...
➤> g(1.0)
1.0
➤> g(0.50196078431372549019)
0.21586050011389926
➤> g(0.25098039215686274509)
0.05126945837404324
So it looks like the colour selector is perceptual RGB, sRGB, even when the image is linear.
I found it useful to look in the Colour Picker info window with the two columns set to RGB (%) and Pixel. E.g. for a pixel entered as RGB #102030, a 32-bit float, perceptual image gives:
Code:
RGB (%) Pixel
R: 6.3% R: 0.062745 16 / 255 = 0.06274509803921568627
G: 12.5% G: 0.125491 32 / 255 = 0.12549019607843137254
B: 18.8% B: 0.188236 48 / 255 = 0.18823529411764705882
Whereas a 32-bit float, linear image gives:
Code:
RGB (%) Pixel
R: 6.3% R: 0.005182 g(16 / 255) = 0.005181516702338386
G: 12.5% G: 0.014444 g(32 / 255) = 0.014443843596092545
B: 18.8% B: 0.029577 g(48 / 255) = 0.0295568344378088
Getting back to the question of a region's pixel data, I am also on a little endian machine and got the same results as you. However, to make generic code we'd need to know if gimp gives the data in native or little endianness.
Perhaps someone on a big endian machine could try your example and post the results.
To check what the endianness is:
Code:
➤> import sys
➤> sys.byteorder
'little'
There's no documentation I've found which states the region data is always native endianness, but looking at GIMP's code to load and save XCF files, it calls functions and macros from Glib which convert pixels in the XCF file's big-endian to native. From then on, I think it just remains native endianness for efficiency.
You can determine endianness on the fly. If you look at my code, if you set a channel to 1 (bucket-fill or else), and re-obtain it and decode it with the wrong endianness, you get a completely invalid answer, so it is easy to determine which endianness should be used