| 00:33 | TofuLynx | 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?
|
| 01:45 | TofuLynx | off to bed. bye bye!
|
| 01:45 | TofuLynx | left the channel |
| 01:52 | TofuLynx | joined the channel |
| 01:57 | TofuLynx | left the channel |
| 01:57 | TofuLynx | joined the channel |
| 04:13 | davidak | left the channel |
| 04:13 | davidak | joined the channel |
| 04:22 | davidak | left the channel |
| 06:33 | Bertl_zZ | changed nick to: Bertl
|
| 06:33 | Bertl | morning folks!
|
| 06:34 | Bertl | TofuLynx: no padding in raw12, it is packed ... there is padding in raw16 though
|
| 07:29 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 07:55 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 09:29 | niemand | joined the channel |
| 09:29 | niemand | left the channel |
| 09:29 | niemand | joined the channel |
| 10:06 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 11:03 | rton | joined the channel |
| 11:43 | TofuLynx | Hello!
|
| 11:46 | TofuLynx | 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?
|
| 11:49 | Bertl | yup
|
| 11:54 | Kjetil_ | joined the channel |
| 11:58 | fredy_ | joined the channel |
| 12:00 | fredy | left the channel |
| 12:00 | Kjetil | left the channel |
| 12:00 | fredy_ | changed nick to: fredy
|
| 12:00 | fredy | changed nick to: Guest35400
|
| 13:23 | TofuLynx | left the channel |
| 13:36 | TofuLynx | joined the channel |
| 13:39 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 13:44 | RexOrCine | left the channel |
| 13:46 | RexOrCine | joined the channel |
| 14:01 | se6astian|away | changed nick to: se6astian
|
| 14:18 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 14:18 | arpu | left the channel |
| 14:22 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 14:22 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 16:13 | futarisIRCcloud | left the channel |
| 16:28 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 16:42 | se6astian | changed nick to: se6astian|away
|
| 16:45 | Kjetil_ | changed nick to: Kjetil
|
| 16:46 | TofuLynx | left the channel |
| 16:46 | TofuLynx | joined the channel |
| 16:48 | TofuLynx | how do I know if I correctly identified each one of the color channels of the raw file?
|
| 16:49 | Bertl | when combining them gives a proper image?
|
| 16:49 | Kjetil | hihi
|
| 16:49 | TofuLynx | well I havent combined them yet
|
| 16:50 | Kjetil | do you know how the image is supposed to look?
|
| 16:50 | TofuLynx | yeah
|
| 16:50 | davidak | joined the channel |
| 16:51 | TofuLynx | the grayscale pictures reveal a man
|
| 16:51 | TofuLynx | with some boxes at the background
|
| 16:51 | Kjetil | If you had the original you could decompose the color layers with gimp.. oh well
|
| 16:52 | TofuLynx | yeah hmm
|
| 16:52 | TofuLynx | i will assume i correctly identified,
|
| 16:52 | TofuLynx | if i get strange colors in the combined image...
|
| 17:13 | se6astian|away | changed nick to: se6astian
|
| 17:27 | TofuLynx | I noticed I have two small 4 pixel wide bars on the left and right sides of the image, is it normal?
|
| 17:27 | TofuLynx | Not a bar with a fixed cor
|
| 17:29 | Bertl | no, that's not normal
|
| 17:30 | TofuLynx | hmm strange
|
| 17:32 | aombk | left the channel |
| 17:34 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 18:21 | TofuLynx | in the 4 layers of colors, two of them seem strange, like with strong color changes and details
|
| 18:21 | TofuLynx | is that normal?
|
| 18:22 | TofuLynx | or should the 4 layers be similar?
|
| 18:22 | Bertl | they are similar but note that green is very 'visible' compare to red or even blue
|
| 18:23 | TofuLynx | well for some reason two of the layers seem very exaggerated
|
| 18:23 | TofuLynx | is it possible to show the image I got?
|
| 18:24 | Bertl | use an image pastebin
|
| 18:25 | TofuLynx | Here's the strange one: https://pasteboard.co/H85QFv7.png
|
| 18:25 | TofuLynx | and the apparent normal one: https://pasteboard.co/H85QShD.png
|
| 18:26 | Bertl | that looks like LSBs and MSBs
|
| 18:27 | Bertl | i.e. in the 'strange' one you are cycling through the available gray values more than once
|
| 18:28 | Bertl | means there is most likely something wrong with the unpacking
|
| 18:33 | TofuLynx | hmm
|
| 18:33 | BAndiT1983 | TofuLynx, how does your method, for conversion of 12 bit to 16 bit, looks like?
|
| 18:35 | TofuLynx | 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
|
| 18:36 | Bertl | BAndiT1983: stop confusing people with a 16 bit conversion :)
|
| 18:36 | BAndiT1983 | it's important to do that step
|
| 18:36 | TofuLynx | why?
|
| 18:37 | BAndiT1983 | you can also shift the bits to get 8 bits, but it's more comfortable first to get 12 bit into 16 bit array
|
| 18:37 | TofuLynx | you mean like
|
| 18:37 | BAndiT1983 | lodepng supports 16bit format, so there is no issue
|
| 18:37 | TofuLynx | a uint16 array?
|
| 18:37 | BAndiT1983 | yes
|
| 18:37 | BAndiT1983 | let me check my sample code
|
| 18:38 | TofuLynx | but the challenge requests for a 8bit image
|
| 18:38 | TofuLynx | does lodepng convert from 16bit to 8?
|
| 18:38 | BAndiT1983 | 8bit conversion is just adding a shift to the bits
|
| 18:38 | BAndiT1983 | don't remember if it does or not, it was some time ago, when i've created sample code to verify the challenge
|
| 18:38 | Bertl | it is perfectly fine to read 12bit and convert it to 8bit directly, just make sure that you are actually reading 12bit
|
| 18:39 | TofuLynx | well, I think I am xD
|
| 18:40 | TofuLynx | but the "strange" image made and the 4 pixel wide bars on the left and right
|
| 18:40 | TofuLynx | make me think there's something wrong with the unpackaging as you said
|
| 18:41 | TofuLynx | and I am suspecting it is related to the LSBs and MSB, with the endian system
|
| 18:42 | BAndiT1983 | hint: take 3 bytes and split them in half to get 2x12bit pixels
|
| 18:42 | TofuLynx | hmm
|
| 18:43 | TofuLynx | that surely does help a lot
|
| 18:43 | BAndiT1983 | you have to merge them first in uint32_t, then do shifting to get 12 bits
|
| 18:43 | Bertl | also not necessary
|
| 18:43 | BAndiT1983 | ?
|
| 18:44 | Kjetil | How is the 12-bits packet into bytes? Big endian?
|
| 18:44 | BAndiT1983 | not in that file
|
| 18:44 | BAndiT1983 | have no byte swap, according to the sample code
|
| 18:46 | BAndiT1983 | we also don't have a header, like TIFF or DNG (which is TIFF extension), to check if it is little- or big-endian
|
| 18:46 | BAndiT1983 | this data stream can be processed as is
|
| 18:47 | BAndiT1983 | Bertl, why is it not necessary?
|
| 18:47 | TofuLynx | hmmm I think i am reading the file the wrong way
|
| 18:48 | BAndiT1983 | how?
|
| 18:50 | TofuLynx | I think I am reading from the end to the start
|
| 18:50 | TofuLynx | which shouldn't happen
|
| 18:51 | TofuLynx | I will check it
|
| 18:51 | BAndiT1983 | ? must be a new functionality in C++ :D
|
| 18:52 | TofuLynx | xD
|
| 18:54 | TofuLynx | the first 3 bytes I read from the file will be RED and then green? right?
|
| 18:54 | BAndiT1983 | nope
|
| 18:54 | BAndiT1983 | bayer image is grayscale one
|
| 18:55 | TofuLynx | huh?
|
| 18:55 | BAndiT1983 | but the intensity is based on the filter of the microlens on the sensor in front of the cell it was read from
|
| 18:55 | TofuLynx | yeah
|
| 18:56 | BAndiT1983 | so you have to know the pattern, e.g. RGGB
|
| 18:56 | TofuLynx | in this case is RGGB, as said on the site, right?
|
| 18:56 | TofuLynx | and the first 3 bytes I read will be the intesity of the red sensor and then the intensity of green sensor?
|
| 18:57 | BAndiT1983 | i think so, haven't checked description lately, was adjusted by several people already
|
| 18:57 | BAndiT1983 | first 3 bytes consist of 2 pixels, e.g. R and G
|
| 18:58 | BAndiT1983 | so the first row of the image has R and G pixels, each channel has an empty pixel in between
|
| 18:58 | TofuLynx | and the next 3 bytes will be R and G again, right?
|
| 18:58 | BAndiT1983 | and second one G and B, same here, empty pixel in every channel between filled ones
|
| 18:58 | BAndiT1983 | yes
|
| 18:58 | TofuLynx | ok :)
|
| 19:02 | BAndiT1983 | http://www.peter-slansky.de/bereiche/astronomie/aufnahmetechniken/bilder/foveon_x3_01.gif
|
| 19:03 | BAndiT1983 | images in first row show what i mean
|
| 19:03 | TofuLynx | yeah
|
| 19:03 | TofuLynx | thanks!
|
| 19:03 | BAndiT1983 | 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
|
| 19:05 | TofuLynx | I see
|
| 19:05 | TofuLynx | yesterday I read that some brands started using CMY bayer sensors
|
| 19:05 | TofuLynx | recently
|
| 19:05 | TofuLynx | that despite being harder to manufacture
|
| 19:06 | BAndiT1983 | there are different versions of bayer sensors, some have bigger and smaller cells together
|
| 19:06 | TofuLynx | have better results
|
| 19:06 | TofuLynx | yeah
|
| 19:17 | BAndiT1983 | off for now
|
| 19:17 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 19:26 | TofuLynx | I changed the approach
|
| 19:26 | TofuLynx | following the 3 byte suggestion of bandit
|
| 19:26 | TofuLynx | and its giving me the exact same result
|
| 19:27 | TofuLynx | two "strange" layers and two "normal" layers
|
| 20:17 | davidak | left the channel |
| 20:17 | davidak | joined the channel |
| 20:29 | davidak | left the channel |
| 20:29 | davidak | joined the channel |
| 20:30 | TofuLynx | 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. :)
|
| 20:39 | Bertl | as I said before, you are obviously using the lower bits of a 12bit value
|
| 20:51 | TofuLynx | and I should use the higher bits?
|
| 20:51 | Bertl | if you have 12bit data, you want to drop the lower 4bit when converting to 8bit, no?
|
| 20:52 | TofuLynx | why doesnt it happen with the other two layers?
|
| 20:52 | TofuLynx | yeah and I do it, supposedly
|
| 20:54 | Bertl | well, don't know your code, but either you are unpacking the wrong bits, or you are dropping the wrong bits
|
| 21:00 | TofuLynx | lets take a case example, if I read those 3 butes: FF854008, i should read 854 for R and read 008 for G, right?
|
| 21:00 | TofuLynx | oops
|
| 21:00 | TofuLynx | 85 for REd and 0 for G
|
| 21:00 | TofuLynx | right?
|
| 21:01 | Bertl | FF8 540 08.
|
| 21:01 | Bertl | but you listed 4byte :)
|
| 21:02 | TofuLynx | sorry xD
|
| 21:02 | TofuLynx | 85 40 08
|
| 21:03 | Bertl | with those, assuming that the bit/byte order is correct
|
| 21:03 | Bertl | 854 and 008 are the 12bit values and thus 85 and 00 the (rounded down) 8 bit values
|
| 21:03 | TofuLynx | yeah
|
| 21:03 | TofuLynx | hmm
|
| 21:16 | niemand | left the channel |
| 21:16 | TofuLynx | I outputted on the console the process of getting the two values from 3 bytes and the behaviour is correct
|
| 21:17 | TofuLynx | so it can be the bit order (?)
|
| 21:18 | Bertl | most likely
|
| 21:18 | TofuLynx | isnt the read from left to right?
|
| 21:18 | TofuLynx | I mean, the common fread()
|
| 21:19 | Bertl | hint: on the wiki is an ImageMagick command to debayer a raw12 image
|
| 21:21 | TofuLynx | left the channel |
| 21:21 | TofuLynx | joined the channel |
| 21:22 | TofuLynx | I'm not sure if that is related to my problem
|
| 21:22 | TofuLynx | will have to check further
|
| 21:46 | BAndiT1983|away | changed nick to: BAndiT1983
|
| 21:47 | BAndiT1983 | TofuLynx, you have to shift right by 4 to get 8 bit from 12
|
| 21:48 | BAndiT1983 | as 854 is out of range of 8 bit
|
| 21:48 | BAndiT1983 | 854 hex is meant
|
| 21:51 | futarisIRCcloud | joined the channel |
| 21:54 | TofuLynx | yes that's what I do
|
| 22:05 | se6astian | changed nick to: se6astian|away
|
| 22:14 | aj_ | joined the channel |
| 22:16 | TofuLynx | left the channel |
| 22:17 | TofuLynx | joined the channel |
| 22:19 | aj_ | "Current Development Status (6th February 2017)" is the 17 only a typo or has the main website not benn updatet?
|
| 22:25 | TofuLynx | good question
|
| 22:30 | BAndiT1983 | where is this?
|
| 22:30 | TofuLynx | https://www.apertus.org/axiom-beta-status
|
| 22:31 | BAndiT1983 | most probably typo, as a couple of people were recently updating stuff in that area
|
| 22:31 | BAndiT1983 | will ask se6astian about it
|
| 22:31 | TofuLynx | ok :)
|
| 22:32 | TofuLynx | I am still stuck on the Strange images
|
| 22:32 | TofuLynx | is it possible to send you a pastebin of the code so you can check it?
|
| 22:32 | BAndiT1983 | can you post your code somewhere?
|
| 22:32 | Kjetil | heh
|
| 22:32 | BAndiT1983 | same idea, 2 people
|
| 22:32 | TofuLynx | ahahah
|
| 22:32 | TofuLynx | Wait a second
|
| 22:36 | TofuLynx | https://pastebin.com/rMkEwPq3
|
| 22:36 | TofuLynx | Here is it
|
| 22:37 | TofuLynx | not sure if it helps
|
| 22:37 | BAndiT1983 | hm, i see a lot of issues there
|
| 22:37 | TofuLynx | but the strange image layers are associated to ValueB
|
| 22:37 | TofuLynx | ValueA*
|
| 22:37 | BAndiT1983 | first i would suggest to read everything into an uint8_t or unsigned char array
|
| 22:38 | BAndiT1983 | there us no need to read it by x and y loops
|
| 22:38 | TofuLynx | why not vector<unsigned char> as lodepng encode needs it?
|
| 22:38 | BAndiT1983 | afterwards you can walk through the array with index += 3
|
| 22:38 | BAndiT1983 | vector has some overhead, so i prefer plain data for such stuff
|
| 22:39 | TofuLynx | Oh I understand
|
| 22:39 | BAndiT1983 | imagine all the conversions if one tries to optimize code through SIMD/SEE and so on
|
| 22:39 | TofuLynx | But do you think there is something wrong?
|
| 22:39 | Kjetil | (I like stdint.h types)
|
| 22:39 | BAndiT1983 | of course, it could happen that some method add alignment while reading, so read the whole file into memory
|
| 22:40 | BAndiT1983 | then just use uint8_t for the array, it's unsigned char
|
| 22:41 | TofuLynx | so you recommend loading the file to memory, then read 3 bytes to load the bits to unsigned char arrays, right?
|
| 22:41 | Kjetil | since you are reading from a file into the memory of a int, you will propably have some endian issues
|
| 22:42 | BAndiT1983 | nope, first you read whole file to uint8_t array, then you walk through it and processing 3 bytes into another uint8_t array
|
| 22:43 | TofuLynx | I will check it bandit
|
| 22:43 | BAndiT1983 | remember -> 3 bytes -> shifting/splitting -> 2 x 8bit values
|
| 22:44 | BAndiT1983 | or to be precise 12bit first
|
| 22:44 | TofuLynx | yeah
|
| 22:44 | TofuLynx | Kjetil
|
| 22:44 | BAndiT1983 | for (long long index = 0; index < length; index += 3)
|
| 22:45 | BAndiT1983 | that's the header of the loop in my sample code
|
| 22:45 | TofuLynx | (I like stdint.h types)
|
| 22:45 | TofuLynx | Are these valuable for this case?
|
| 22:45 | BAndiT1983 | ?
|
| 22:45 | TofuLynx | and length is 3072*4096?
|
| 22:46 | TofuLynx | I am referring to kjetil, sorry xD
|
| 22:46 | BAndiT1983 | length is the filesize length
|
| 22:46 | TofuLynx | but shouldn't it avoid the possible appended image sensor registers dump?
|
| 22:46 | Kjetil | I just get this fuzzy feeling with standard C-types. As their sizes are quite CPU dependent
|
| 22:47 | BAndiT1983 | no sensor registers there, just plain data stream from photo cells
|
| 22:47 | TofuLynx | ah ok
|
| 22:47 | TofuLynx | so I don't need to worry about it?
|
| 22:48 | BAndiT1983 | no, not at all
|
| 22:54 | Kjetil | #include "lodepng.cpp" - please use the header file instead ?
|
| 22:54 | TofuLynx | oops
|
| 22:54 | TofuLynx | fixed
|
| 22:54 | TofuLynx | also
|
| 22:55 | TofuLynx | What kind of approach do you use to get the file size in bytes? fstream?
|
| 22:58 | Kjetil | I get you can use fseek,SEEKEND and ftell iirc
|
| 22:58 | Kjetil | guess*
|
| 22:58 | TofuLynx | yeah but from what I read it could give errors in some cases
|
| 22:59 | TofuLynx | But I guess in this case it's not particularly important
|
| 22:59 | BAndiT1983 | try it first, before assuming from docs
|
| 22:59 | BAndiT1983 | using ifstream nowadays
|
| 22:59 | BAndiT1983 | in.seekg(0, std::ios::end);
|
| 22:59 | BAndiT1983 | length = in.tellg();
|
| 22:59 | BAndiT1983 | in.seekg(0, std::ios::beg);
|
| 23:01 | aj_ | left the channel |
| 23:02 | TofuLynx | Thanks!
|
| 23:04 | BAndiT1983 | off for today
|
| 23:05 | BAndiT1983 | changed nick to: BAndiT1983|away
|
| 23:13 | davidak | left the channel |
| 23:13 | davidak | joined the channel |
| 23:17 | davidak | left the channel |
| 23:17 | davidak | joined the channel |
| 23:29 | Bertl | off to bed ... have a good one!
|
| 23:29 | Bertl | changed nick to: Bertl_zZ
|
| 23:29 | TofuLynx | Good Night!
|
| 23:33 | aombk | joined the channel |
| 23:43 | TofuLynx | By using this for loop " for (long long index = 0; index < length; index += 3) ", how do you know when it's a odd or even row, so that you can identify if it is a RG row or GB row
|
| 23:43 | TofuLynx | ?
|
| 23:45 | davidak | left the channel |
| 23:45 | davidak | joined the channel |
| 23:47 | davidak | left the channel |
| 23:47 | davidak | joined the channel |
| 23:53 | rton | left the channel |