how do i open raw images in gimp without installing darktable? darktable sucks and i never want to use it
/Cinny
@eri rawtherapee /j
there imo isnβt much you can do with raws without developing them in something like darktable
@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β
@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
@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
/Cinny
@eri if opening a raw in am image editor was a thing you could do it would look something like this.
this is a color image
@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
@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.
/Cinny
@eri also png is so good that the image is about 12MB larger than the RAW lmfao
@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.
/Cinny
@eri an svg rasterizer is well more well defined and has fewer quirks than developing a raw. a one-stop solution kinda is hardware specific and itβs the incredibly complex image processing of the camera used for non-raw-images
@charlotte i donβt care just put the pixels on the screen. itβs my computer let me do things stupid and wrong.
/Cinny
@eri PNG has the issue that halfway through it forgets that >8BPC images exists and then treats each byte as a separate pixel which uh
doesnβt work for >8BPC images! they are so fucking huge!!
/Cinny
@eri would you consider the image i posted usable, keeping in mind that it is a color image not monochrome?
@charlotte yes i can see the plushie β€οΈ
@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β
/Cinny
@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
/Cinny
/Cinny
@eri install dcraw and convert them on the command line