eri 
eri@mk.moth.zone
how do i open raw images in gimp without installing darktable? darktable sucks and i never want to use it
2
0
0
@charlotte they’re not magic, they’re just uncompressed images. why is everything in photography stupid like this. is it because making it annoying and difficult is how you feel like you’re being a “professional”
2
0
0
@charlotte if rawtherapee doesn’t pop up a stupid window and then run in the background and have a weird database that exists only to get corrupted every time you try and do anything, ig i might put up with it
1
0
0
@charlotte well it seems to be less dogshit than darktable but why can’t i just open it directly in GIMP. i don’t care about perfect quality. this is all just fucking numbers just put the pixels on the screen its not that hard
0
0
0
@charlotte ok and? if we don’t arbitrarily downsample during the import it’ll be fine.
why does GIMP just happily let you open an SVG or PDF, but no, if we wanna open a DNG or whatever you just aren’t allowed to
2
0
0
@charlotte like if the logic you’re using here was true, GIMP would refuse to open SVG files, and instead insist that you must open them using Inkscape and then convert them properly there.
1
0
0
@charlotte png is a hilariously overengineered format tho
i love how some guy got bored one day and wrote a format that’s literally simple enough to include the full spec in this post, and yet it compresses just as well as PNG + is faster
A QOI file consists of a 14-byte header, followed by any number ofdata “chunks” and an 8-byte end marker. qoi_header { char magic[4]; // magic bytes "qoif" uint32_t width; // image width in pixels (BE) uint32_t height; // image height in pixels (BE) uint8_t channels; // 3 = RGB, 4 = RGBA uint8_t colorspace; // 0 = sRGB with linear alpha // 1 = all channels linear }; The colorspace and channel fields are purely informative. They do not change the way data chunks are encoded. Images are encoded row by row, left to right, top to bottom. The decoder and encoder start with {r: 0, g: 0, b: 0, a: 255} as the previous pixel value. An image is complete when all pixels speci- fied by width * height have been covered. Pixels are encoded as: • a run of the previous pixel • an index into an array of previously seen pixels • a difference to the previous pixel value in r,g,b • full r,g,b or r,g,b,a values The color channels are assumed to not be premultiplied with the alpha channel (“un-premultiplied alpha”). A running array[64] (zero-initialized) of previously seen pixel values is maintained by the encoder and decoder. Each pixel that is seen by the encoder and decoder is put into this array at the position formed by a hash function of the color value. In the encoder, if the pixel value at the index matches the current pixel, this index position is written to the stream as QOI_OP_INDEX. The hash function for the index is: index_position = (r * 3 + g * 5 + b * 7 + a * 11) % 64 Each chunk starts with a 2- or 8-bit tag, followed by a number of data bits. The bit length of chunks is divisible by 8 - i.e. all chunks are byte aligned. All values encoded in these data bits have the most significant bit on the left. The 8-bit tags have precedence over the 2-bit tags. A decoder must check for the presence of an 8-bit tag first. The byte stream's end is marked with 7 0x00 bytes followed by a single 0x01 byte. The possible chunks are: ┌─ QOI_OP_RGB ────────────┬─────────┬─────────┬─────────┐ │ Byte[0] │ Byte[1] │ Byte[2] │ Byte[3] │ │ 7 6 5 4 3 2 1 0 │ 7 .. 0 │ 7 .. 0 │ 7 .. 0 │ │─────────────────────────┼─────────┼─────────┼─────────│ │ 1 1 1 1 1 1 1 0 │ red │ green │ blue │ └─────────────────────────┴─────────┴─────────┴─────────┘ 8-bit tag b11111110 8-bit red channel value 8-bit green channel value 8-bit blue channel value The alpha value remains unchanged from the previous pixel. ┌─ QOI_OP_RGBA ───────────┬─────────┬─────────┬─────────┬─────────┐ │ Byte[0] │ Byte[1] │ Byte[2] │ Byte[3] │ Byte[4] │ │ 7 6 5 4 3 2 1 0 │ 7 .. 0 │ 7 .. 0 │ 7 .. 0 │ 7 .. 0 │ │─────────────────────────┼─────────┼─────────┼─────────┼─────────│ │ 1 1 1 1 1 1 1 1 │ red │ green │ blue │ alpha │ └─────────────────────────┴─────────┴─────────┴─────────┴─────────┘ 8-bit tag b11111111 8-bit red channel value 8-bit green channel value 8-bit blue channel value 8-bit alpha channel value ┌─ QOI_OP_INDEX ──────────┐ │ Byte[0] │ │ 7 6 5 4 3 2 1 0 │ │───────┼─────────────────│ │ 0 0 │ index │ └───────┴─────────────────┘ 2-bit tag b00 6-bit index into the color index array: 0..63 A valid encoder must not issue 2 or more consecutive QOI_OP_INDEX chunks to the same index. QOI_OP_RUN should be used instead. ┌─ QOI_OP_DIFF ───────────┐ │ Byte[0] │ │ 7 6 5 4 3 2 1 0 │ │───────┼─────┼─────┼─────│ │ 0 1 │ dr │ dg │ db │ └───────┴─────┴─────┴─────┘ 2-bit tag b01 2-bit red channel difference from the previous pixel -2..1 2-bit green channel difference from the previous pixel -2..1 2-bit blue channel difference from the previous pixel -2..1 The difference to the current channel values are using a wraparound operation, so 1 - 2 will result in 255, while 255 + 1 will result in 0. Values are stored as unsigned integers with a bias of 2. E.g. -2 is stored as 0 (b00). 1 is stored as 3 (b11). The alpha value remains unchanged from the previous pixel. ┌─ QOI_OP_LUMA ───────────┬─────────────────────────┐ │ Byte[0] │ Byte[1] │ │ 7 6 5 4 3 2 1 0 │ 7 6 5 4 3 2 1 0 │ │───────┼─────────────────┼─────────────┼───────────│ │ 1 0 │ diff green │ dr - dg │ db - dg │ └───────┴─────────────────┴─────────────┴───────────┘ 2-bit tag b10 6-bit green channel difference from the previous pixel -32..31 4-bit red channel difference minus green channel difference -8..7 4-bit blue channel difference minus green channel difference -8..7 The green channel is used to indicate the general direction of change and is encoded in 6 bits. The red and blue channels (dr and db) base their diffs off of the green channel difference. I.e.: dr_dg = (cur_px.r - prev_px.r) - (cur_px.g - prev_px.g) db_dg = (cur_px.b - prev_px.b) - (cur_px.g - prev_px.g) The difference to the current channel values are using a wraparound operation, so 10 - 13 will result in 253, while 250 + 7 will result in 1. Values are stored as unsigned integers with a bias of 32 for the green channel and a bias of 8 for the red and blue channel. The alpha value remains unchanged from the previous pixel. ┌─ QOI_OP_RUN ────────────┐ │ Byte[0] │ │ 7 6 5 4 3 2 1 0 │ │───────┼─────────────────│ │ 1 1 │ run │ └───────┴─────────────────┘ 2-bit tag b11 6-bit run-length repeating the previous pixel: 1..62 The run-length is stored with a bias of -1. Note that the run- lengths 63 and 64 (b111110 and b111111) are illegal as they are occupied by the QOI_OP_RGB and QOI_OP_RGBA tags.
1
0
0
@charlotte i don’t care just put the pixels on the screen. it’s my computer let me do things stupid and wrong.
1
0
0
@eri would you consider the image i posted usable, keeping in mind that it is a color image not monochrome?
2
0
0
Show content
@charlotte yes i can see the plushie ❤️
0
0
1
Show content
@eri @charlotte as someone who’s way too knees deep into computer graphics, they’re not “just” uncompressed images, they’re images that you can’t send directly to a framebuffer, they’re images with values that don’t make any coherent sense, they’re images that the pipelines used to modify and show them to the screen weren’t GPU-accelerateable until a decade ago, they’re images where you can forget about colourspaces altogether because that sometimes just isn’t embedded into the image, they’re images that CG people on the PBR and realism side spent decades trying to replicate the processes of rendering of because it’s hard as shit even when you can control all the parameters and have a perfectly clean image. they’re images whose research laid the foundation for RGB gamer HDR monitors and any lighting techniques more advanced than the blinn-phong model. an uncompressed image would be a .gif or a .bmp not a raw
for a software like GIMP, there’s a ton of assumptions about images made from the very beginning of CG history that only apply if your image is linear RGB with premultiplied alpha in the integer range 0-255. there’s a ton of assumptions about how colours are meant to be blended and how they’re meant to be rendered. even for Krita that has experimental support for colourspaces that’s not just different Srgb profiles, it’s slow and clunky and doesn’t work with most of the tools you’ve come to expect to work out of the box with RGB and unoptimised as hell because no hardware support, on top of having to translate the entire image to Srgb anyway for displaying because no hardware support. and alpha blending probably doesn’t work as you’d expect either because premultiplied alpha is an assumption that can’t be applied to a lot of colourspaces because it assumes that both the colour components and the alpha component are linear so you can linearly blend the colours without unnecessary multiplications and divisions
all of that in the framework of “there may not be gpu acceleration and there might never be” and having to write both the software and gpu pipeline. and then the reality of “handling raw images only being possible to be gpu accelerated since a decade ago”.
and then there’s the part of “yes you can bake the RAW image into something you can use with the rest of the pipeline” but like, it’s extremely nontrivial to implement. there’s a ton more stuff about RAW that’s hard that I’m not mentioning because I don’t work on RAW image editors, but i know that so much of the things that i do look at and work on are dependent on the research into how to make digital cameras from “impossible wet dream” to “almost trivial enough to be widespread”
1
0
0
Charlotte 
/Cinny 
charlotte
Show content
@twinkle @eri yeah that is what i tried to racconvey with https://akko.chir.rs/objects/a387d45a-7e1c-4c98-9d2a-e6d696b7eeae
It’s as racclose as i could turn a raw into a png with darktable while disabling as much processing as possible
like sure the general Shape of the image is accurate, but color is missing, lighting is wrong, the relative brightness differences are Wrong (because it’s linear) and the file is also more massive than the original
1
0
1
@charlotte @eri fucking banger image though btw I love the creature
1
0
0
Charlotte /Cinny
charlotte
1
1
1
@charlotte @twinkle you can microwave me too if you want
2
0
1
Charlotte /Cinny
charlotte
0
0
1
@eri @charlotte @twinkle me too me too :<
0
0
0
CmykStudent
CmykStudent@fosstodon.org@eri @charlotte GIMP can open SVGs and PDFs because people wrote native plug-ins to do this. To open RAW files natively, someone(s) would have to do the same thing for those. :)
0
0
0