#apertus IRC Channel Logs

in a 12 bits raw image file, for each 12 bits in the file, I have to add 4 zeroes next it? Aka bit padding?

morning folks!

I'am not sure if it's correct, but if I took one of the four colours of a raw file, and made a image with half the width and height with it as requested, shouldn't it be a continuous picture? without the normal separations between same pixel colors in the raw image?

how do I know if I correctly identified each one of the color channels of the raw file?

hihi

do you know how the image is supposed to look?

with some boxes at the background

yeah hmm

if i get strange colors in the combined image...

I noticed I have two small 4 pixel wide bars on the left and right sides of the image, is it normal?

no, that's not normal

in the 4 layers of colors, two of them seem strange, like with strong color changes and details

or should the 4 layers be similar?

well for some reason two of the layers seem very exaggerated

use an image pastebin

and the apparent normal one: https://pasteboard.co/H85QShD.png

i.e. in the 'strange' one you are cycling through the available gray values more than once

hmm

I didn't do the conversion, I read 12 bits each time and the put the value shifted right 4 times (so it is 8 bits) and insert it in the grayscale vector of the respective color layer

it's important to do that step

you can also shift the bits to get 8 bits, but it's more comfortable first to get 12 bit into 16 bit array

lodepng supports 16bit format, so there is no issue

yes

but the challenge requests for a 8bit image

8bit conversion is just adding a shift to the bits

it is perfectly fine to read 12bit and convert it to 8bit directly, just make sure that you are actually reading 12bit

but the "strange" image made and the 4 pixel wide bars on the left and right

and I am suspecting it is related to the LSBs and MSB, with the endian system

hmm

you have to merge them first in uint32_t, then do shifting to get 12 bits

?

not in that file

we also don't have a header, like TIFF or DNG (which is TIFF extension), to check if it is little- or big-endian

Bertl, why is it not necessary?

how?

which shouldn't happen

? must be a new functionality in C++ :D

the first 3 bytes I read from the file will be RED and then green? right?

bayer image is grayscale one

but the intensity is based on the filter of the microlens on the sensor in front of the cell it was read from

so you have to know the pattern, e.g. RGGB

and the first 3 bytes I read will be the intesity of the red sensor and then the intensity of green sensor?

first 3 bytes consist of 2 pixels, e.g. R and G

and the next 3 bytes will be R and G again, right?

yes

http://www.peter-slansky.de/bereiche/astronomie/aufnahmetechniken/bilder/foveon_x3_01.gif

yeah

second row shows other type of sensor, where the layers are fully exposed, but they also have other problems, like color shifting, because of manufacturing differences

yesterday I read that some brands started using CMY bayer sensors

that despite being harder to manufacture

have better results

off for now

I changed the approach

and its giving me the exact same result

https://pasteboard.co/H85QFv7.png this is the "strange" image I get in two of the four layers. If anybody knows anything that may cause it, it would be great to explain me. :)

and I should use the higher bits?

why doesnt it happen with the other two layers?

well, don't know your code, but either you are unpacking the wrong bits, or you are dropping the wrong bits

oops

right?

but you listed 4byte :)

85 40 08

854 and 008 are the 12bit values and thus 85 and 00 the (rounded down) 8 bit values

hmm

I outputted on the console the process of getting the two values from 3 bytes and the behaviour is correct

most likely

I mean, the common fread()

I'm not sure if that is related to my problem

as 854 is out of range of 8 bit

"Current Development Status (6th February 2017)" is the 17 only a typo or has the main website not benn updatet?

where is this?

most probably typo, as a couple of people were recently updating stuff in that area

ok :)

is it possible to send you a pastebin of the code so you can check it?

heh

ahahah

https://pastebin.com/rMkEwPq3

not sure if it helps

but the strange image layers are associated to ValueB

first i would suggest to read everything into an uint8_t or unsigned char array

why not vector<unsigned char> as lodepng encode needs it?

vector has some overhead, so i prefer plain data for such stuff

imagine all the conversions if one tries to optimize code through SIMD/SEE and so on

(I like stdint.h types)

then just use uint8_t for the array, it's unsigned char

since you are reading from a file into the memory of a int, you will propably have some endian issues

I will check it bandit

or to be precise 12bit first

Kjetil

that's the header of the loop in my sample code

Are these valuable for this case?

and length is 3072*4096?

length is the filesize length

I just get this fuzzy feeling with standard C-types. As their sizes are quite CPU dependent

ah ok

no, not at all

oops

also

I get you can use fseek,SEEKEND and ftell iirc

yeah but from what I read it could give errors in some cases

try it first, before assuming from docs

in.seekg(0, std::ios::end);

in.seekg(0, std::ios::beg);

Thanks!

?