alecjacobson / computer-graphics-raster-images Goto Github PK

Hello!

In class, it was mentioned that we would submit assignments through GitHub, and Prof. Singh said that there are instructions on how to do this on the assignment handout (IIRC). However, the assignment instructions ask us to submit through MarkUs. How will submission really work?

Thanks!

Hi guys,

I noticed that for some machines (my personal pc and some U of T clusters),
the original project (no modifications made, fresh cloned) could be compiled, but throws segmentation fault if run.

I am using Ubuntu 18.04.1 LTS, cmake 3.10.2, g++ (Ubuntu 7.3.0-16ubuntu3) 7.3.0, with libstdc++.so.6

Program received signal SIGSEGV, Segmentation fault.
__strlen_avx2 () at ../sysdeps/x86_64/multiarch/strlen-avx2.S:62
62      ../sysdeps/x86_64/multiarch/strlen-avx2.S: No such file or directory.
(gdb) up
#1  0x00007ffff7b7282b in std::__cxx11::basic_string<char, std::char_traits<char>, std::allocator<char> >::basic_string(char const*, std::allocator<char> const&) () from /usr/lib/x86_64-linux-gnu/libstdc++.so.6
(gdb) up
#2  0x000055555556f0f6 in main (argc=1, argv=0x7fffffffdcf8) at /home/wtw/csc2504/csc418-A1/main.cpp:97
97          read_rgba_from_png(input_filenames[f],next_rgba,next_width,next_height);

I suspect it has something to do with c++'s implicit constructor, as the function
inline bool read_rgba_from_png asks for

const std::string & filename

while is provided with

input_filenames = const_cast<char **>(default_input_file_names);
...
input_filenames[f]

After fixing line 18-29 from main.cpp into

  const std::string input_filenames[] = {
      "../shared/data/dog.png",
      "../shared/data/glasses.png",
      "../shared/data/laser-beams.png",
      "../shared/data/sparkles.png"
  };
  int num_inputs = 4;

it could be compiled and run correctly.

I am not familiar with C++, and I might have made some silly mistakes here.
It will be great if someone could help. And btw, is there a way we could test if our project could be compiled correctly when tested?

Thx in advance ;P

The handout did not mention how to determine each pixel of the grayscale mosaic. My understanding is that we have to reduce each pixel of the RGB image to one of the three channels, depending on the location of the pixel, is that correct?

On the linked Wikipedia page, there are 2 calculations for hue.
The main difference is for the condition when the maximum value is red,
the first equation defines hue as (G - B / C) MOD 6
whereas the second equation defines hue as (G - B / C) + 0

The second equation also avoids negative values of hue by adding 360

How are the 2 equations the same and is there any restrictions on which one we should use?

thanks

Not sure what i am doing wrong here?

Hi guys, I have read through the issue and read some documents online about the demosaic, however, I keep getting a greenish color image ..... what I did here is the following:
For example, if the current index in Bayer is a blue, ie(meaning it is on an even row and an odd column ) so I should just take avg value from its horizontal, vertical neighbors((4 of them) as value for red color and the avg value of its diagonal neighbors as value for green color(4 of them)..... I think I did it correctly however the image is still somewhat gree... what may be the cause of this? Can anyone give me some hint?

Note: ignore the black line around it.

I initially wrote my code in windows and it was able to compile and run perfectly. To double check that my code works, I use a Ubuntu VM to check if my code was able to run under a linux environment, the compilation finished without any error but if I run the program without argument, it produces a seg fault:

And from the output I can see that it crashed when performing the composite step, I also did some verification by edit main.cpp and am sure that the seg fault is caused by the file name array input_filenames. Also if I run the program by entering the file paths manually, it doesn't produce any error:

I'm not very familiar with C++ but this feels like something wrong with the string array declaration in main.cpp? Specifically this section:

  int num_inputs = argc-1;
  if(num_inputs == 0)
  {
    const char * default_input_file_names[] = {
      "../data/dog.png",
      "../data/glasses.png",
      "../data/laser-beams.png",
      "../data/sparkles.png"
    };
    input_filenames = const_cast<char **>(default_input_file_names);
    num_inputs = 4;

Also can we get the environment specification used for marking so we can make sure that our code can run?

When png is loaded it's width & height are zero. When I try to open dog.png from terminal given warning: "eom:22117): Gtk-WARNING **: Allocating size to EomStatusbar 0x560a001b46c0 without calling gtk_widget_get_preferred_width/height(). How does the code know the size to allocate?"

When I was working with the function rgba_to_rgb and write_ppm, it seems that something went wrong with the function inputs. The input width is 0, the input height is 5079144 and the size of the input vector is 0. Can anyone help me with this?

Hi, I countered some difficulties when I try to implement write ppm.
My output ppm seems to be a quarter of the original xxx.ppm.png file. I tried to debug my code several times but I didn't solve the problem.
I was using "P6" as magic number.

From the some conversion formulas from internet, I get the following hue shift image. However, I can see some green noise in the image. Is this a fine output?

if so is there a file for offset of what information is contained in metadata and the offset on each information for the ppm files in binary format.
or we simply just write a hw3 array into the file?

When trying https://github.com/alecjacobson/computer-graphics-raster-images#execution

I found I am unable to run ./raster because raster is not found in the build directory. I didnt see any error during compile using cmake .. and here is the ls for build dir:

Mode                LastWriteTime         Length Name
----                -------------         ------ ----
d-----        2018/9/13      1:26                CMakeFiles
-a----        2018/9/13      1:26          44968 ALL_BUILD.vcxproj
-a----        2018/9/13      1:26            331 ALL_BUILD.vcxproj.filters
-a----        2018/9/13      1:26          13671 CMakeCache.txt
-a----        2018/9/13      1:26           1535 cmake_install.cmake
-a----        2018/9/13      1:26           3195 raster.sln
-a----        2018/9/13      1:26          58163 raster.vcxproj
-a----        2018/9/13      1:26           2797 raster.vcxproj.filters
-a----        2018/9/13      1:26          44146 ZERO_CHECK.vcxproj
-a----        2018/9/13      1:26            574 ZERO_CHECK.vcxproj.filters

I could see a raster.sln file. Ideally should an raster.exe comes out? What should I do to execute the raster output?

I was having trouble getting the hue but now I solved it. Just to make other people's life easier (if they got the same problem as me), the formula I used (hsv2rgb and rgb2hsv) is from wiki: https://en.wikipedia.org/wiki/HSL_and_HSV#HSL_to_RGB.
Also, you need to make sure when adding 180, you have to check if it's over 360 or under 360 since wiki's formula does not check it.

The readme seems to have the submission link to the MarkUs site for last year. Could it be updated to the one for this year? Thanks!

Does semi-transparent rgba images mean we need to change transparency to 0.5 out of 1 in the a and b RGBA? like in a from 255 to 255/2 and b from 0 to 255/2?

It seems that the height and width in the rotate function refer to the height and width of the Input, not the new rotated image. Just letting people know as I got stuck on this for a little bit XD.

I am reading Wikipedia to find out a way to implement over function.

In Wikipedia, there are two transformations for color: one is divided by new alpha in the end while the other is use the linear combination of pixels of destination, source and both region. I am confused.

Can anyone can help me to explain what the different is between these two rgb style?

Thanks in advance.

So I understand the ordering "GBRG" for bayer pattern, even rows containing GBGB... and odd rows containing RGRG...

But when creating the output which should be single channel, do we have to slide through each row in windows of 3 bytes (i.e 3 channels) and convert the first byte in each window to its respective grascale intensity and ignore the last 2 bytes in the window? For example the 2nd window at first row starts with a Blue channel so I multiply the value by "0.0722" and move on to the next window?

Following the above scheme, the output I get is a bit darker than what I see in the README.

I observed that for example float 60.5 is rounded to 60 when cast to unsigned char from float. Is this okay or we are expected to round it up to 61

Sorry for this rather silly question. I just want to make sure I am not oversimplifying/misunderstanding the problem.

For rgba_to_rgb do we simply discard the alpha values and write the rgb values? For example, if the rgba vector was (255, 0, 255, 31) the resulting rgb vector will be (255, 0, 255)?

In the instructions for rotate.cpp it says to rotate the image by 90 degrees ccw, but the shown image is reflected across y=-x (if it's rotated then the nose should be pointing up). So should we implement rotate.cpp so that the outcome resembles the image shown in the instructions?

ie. No image that has width = 1 or height = 1

The saturation of two example files does not agree (desaturated.png desaturated.ppm.png), which one should we mimic? It is fairly trivial to get close to desaturated.png but when I try to get desaturated.ppm.png with a change in math, I ended up with very desaturated pictures.

I find that when my code converts the rgba image to an rgb image, the two versions of the image are not identical. I suppose this is expected, but am I right? Can I post the image my code produces here to confirm?

will coding styles (documentations, indentations etc.) be a part of the marking rubric?

Hi guys, I have read the issue posted before, but the desaturated image I create does not match exactly with the image under the image folder.
my result:

image from the folder:

You can see that color around the eye does not really match...Is it tolerable ?

The README states that we need to "Simulate an image acquired from the Bayer mosaic by taking a 3-channel rgb image and creating a single channel grayscale image composed of interleaved red/green/blue channels. The output image should be twice as big (but only one channel)."

My first inclination is that we should be mapping one of each pixel's particular RGB value to greyscale output (ie; (0, 0) pixel only reports the green value, (1, 0) reports blue etc). This however, doesn't conform to the specification that the image should be twice as large.

My second though was to map each pixel in the input image to 4 separate grayscale pixels in the new image as per the Bayer pattern. However, in the starter code, the bayer matrix is resized to (widthheight) instead of (widthheight*4). Based on bayer.ppm.png (under /images, it has a height and width twice that of the other pngs), this is what I think we're supposed to do, but this should probably be reflected with a change to the starter code. This is also 4 times as large, not twice.

If one of the profs could clarify on this, it would be appreciated.

I know that we can use std::fabs(),std::max(),std::min(), but just want to confirm that we can include right?

When creating the bayer mosaic, if a pixel should have the green value, do we simply keep the green value and discard the values for red and blue? or is the value we keep an average of the surrounding pixels??

thanks

For the grayscale output, should it be a RGB .ppm file (with magic number P6), but visually in grayscale? Or should it be a real grayscale PGM (with magic number P5)?

My code could be builded with cmake on debug mode, whereas when I try to do the release mode, I got a weird error like

libhw2.a(Triangle.cpp.o): In function Triangle::intersect(Ray const&, double, double&, Eigen::Matrix<double, 3, 1, 0, 3, 1>&) const':
Triangle.cpp:(.text+0x2db): undefined reference to Eigen::MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >::cross_product_return_type<Eigen::Matrix<double, 3, 1, 0, 3, 1> >::type Eigen::MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> >::cross<Eigen::Matrix<double, 3, 1, 0, 3, 1> >(Eigen::MatrixBase<Eigen::Matrix<double, 3, 1, 0, 3, 1> > const&) const' collect2: error: ld returned 1 exit status CMakeFiles/raytracing.dir/build.make:225: recipe for target 'raytracing' failed make[2]: *** [raytracing] Error 1 CMakeFiles/Makefile2:67: recipe for target 'CMakeFiles/raytracing.dir/all' failed make[1]: *** [CMakeFiles/raytracing.dir/all] Error 2 Makefile:83: recipe for target 'all' failed make: *** [all] Error 2 b2210-10:~/CSC418/ray_tracing/release% make
The reason why this happens is that we miss an #include <Eigen/Geometry> in include/Triangle.h.
Hope this may help anyone with similar issues...

When I wrote hue shift, I tested by converting from rgb to hsv then convert back, however, I noticed about 4% pixels, each pixel changes by 1 i.e. 134->135, this is probably due to accuracy issue of double and math libs, should I be worry about this?

What pattern do we need to produce? BGGR or GBRG?? Does it even matter? Below is the comments in header file and it contradicts itself.

// Given a mosaiced image (interleaved BGGR colors in a single channel), created
// a 3-channel rgb image.
//
// Inputs:
// bayer width*height array containing interleaved color intensities in
// the GBRG bayer pattern.

Are we supposed to use P6 instead of P3? I am using P3 right now which is easier to debug

Hi guys,

The reference de-saturated image seems to be desaturated to 25% instead of by 25%.

Is it something we should worry about, or was the reference image simply just made with some other random factor (which is not 25%)?

Thx in advance

Under "Mosaic images":
"So for each pixel, we'll use the exact color sample when it's available and average available neighbors (in all 8 directions) to fill in missing colors."

Does this mean that we should factor in the RGB values that we've already approximated? Wouldn't this lead to different results depending on what order we fill the pixels?

I'm trying to write the header portions for my ppm file and I am getting unexpected values (big, negative values) saved in the width and height variables, resulting in the header looking like this:

P6
-858993460 -858993460
255

I was expecting the width and height to be 383 and 385. Not sure why I am getting these values. Did anyone encounter this?

Are we allowed to assume that Bayer mosaic images are at least 2x2 in dimensions?
If not, what do we do for a Bayer mosaic image that looks like the following?

In the above image we have no neighboring red pixels to use for averaging, so how do we fill the red component for each pixel?

Depending how values are rounded, I think my generated images may be different from the solution by +-1 on many pixels. How exact is the marking for this assignment? I.e. are small differences in pixel values okay?

not able to build the project.

CMake Error at CMakeLists.txt:4 (include):
  include could not find load file:

    /Users/mingrenchen/Desktop/csc418/computer-graphics-raster-images/shared/cmake/CMakeLists.txt

Working on write_ppm.cpp, I'm using the following header:
P6
255
width height
But my image only displays a quarter of the dog.
I saw the rgb.ppm.png in the images folder and its width and height are twice that of the rgb.png, does that mean the width and height of the .ppm should be 2width and 2height?

Preview on mac couldn't view ppm files, is there anything else?

I'm not very familiar with visual studio and it is producing this error
`Error CMake Error at C:\Users\Jimmy\Source\Repos\Assignment1\alecjacobson\computer-graphics-raster-images\CMakeLists.txt:2 (project):
No CMAKE_C_COMPILER could be found.

Tell CMake where to find the compiler by setting either the environment
variable "CC" or the CMake cache entry CMAKE_C_COMPILER to the full path to
the compiler, or to the compiler name if it is in the PATH. raster C:\Users\Jimmy\Source\Repos\Assignment1\alecjacobson\computer-graphics-raster-images\CMakeLists.txt 2
`
Is the way I'm compiling on visual studio wrong? This is my first time using visual studio.

Is it ok to just do an average of rgb or there is a specific ratio we need to follow. I'm asking this since averaged rgb grayscale doesn't really match the provided one.

I am following the explanation of Porter/Duff operators from this page http://ssp.impulsetrain.com/porterduff.html and it's not clear to me how to calculate the resulting alpha value, what are the operators [as] [ad] [ab]? On the web page it says that these values should be 0 or 1 depending on whether source or destination pixel is present and [ab] should be 0 if both region is empty (so its 1 in our case). However if I use this formula I am getting a weird image where the dog is clearly visible but all the images after that are missing some colors. I am I using the formula wrong? I appreciate any help.

Under "Mosaic images":
"So for each pixel, we'll use the exact color sample when it's available and average available neighbors (in all 8 directions) to fill in missing colors."

Does this mean that for every pixel in the bayer.ppm we look at all the neighbors (mostly 8 neighbors), find the average and then assign the values to be the color channels which is NOT the current color channel being observed in the bayer.ppm ?
For example, if the current pixel being observed in bayer.ppm is a red filter, then we would fill in the green and blue values with the average neighbors and the red values with the current value in the pixel being observed at bayer.ppm.

Doing this will lose color information in the original RGB image and the demosaic.ppm will look slightly different (because of the colors) from the original image right?
I'm just wondering why the sample image in computer-graphics-raster-images/images/demosaicked.ppm.png looks exactly the same as the original image?

Just to give an idea, this is what the color of my demosaic.ppm looks like after running with the simple algorithm.

I'm on the Linux ECF machines and was having issues running the make command. I cloned a fresh copy of the repo and cmake from the build folder runs fine, but when I run make a host of errors all related to being unable to locate the eigen library are printed:

In file included from /u/c/sissonde/computer-graphics-ray-casting/include/Plane.h:4,
from /u/c/sissonde/computer-graphics-ray-casting/src/Plane.cpp:1:
/u/c/sissonde/computer-graphics-ray-casting/include/Object.h:4:22: error: Eigen/Core: No such file or directory
In file included from /u/c/sissonde/computer-graphics-ray-casting/include/Plane.h:4,
from /u/c/sissonde/computer-graphics-ray-casting/src/Plane.cpp:1:
/u/c/sissonde/computer-graphics-ray-casting/include/Object.h:24: error: ‘Eigen’ has not been declared
/u/c/sissonde/computer-graphics-ray-casting/include/Object.h:24: error: expected ‘,’ or ‘...’ before ‘&’ token
In file included from /u/c/sissonde/computer-graphics-ray-casting/src/Plane.cpp:1:
/u/c/sissonde/computer-graphics-ray-casting/include/Plane.h:11: error: ‘Eigen’ has not been declared
/u/c/sissonde/computer-graphics-ray-casting/include/Plane.h:11: error: ISO C++ forbids declaration of ‘Vector3d’ with no type
/u/c/sissonde/computer-graphics-ray-casting/include/Plane.h:11: error: expected ‘;’ before ‘point’
/u/c/sissonde/computer-graphics-ray-casting/include/Plane.h:13: error: ‘Eigen’ has not been declared
/u/c/sissonde/computer-graphics-ray-casting/include/Plane.h:13: error: ISO C++ forbids declaration of ‘Vector3d’ with no type
/u/c/sissonde/computer-graphics-ray-casting/include/Plane.h:13: error: expected ‘;’ before ‘normal’
/u/c/sissonde/computer-graphics-ray-casting/include/Plane.h:24: error: ‘Eigen’ has not been declared
/u/c/sissonde/computer-graphics-ray-casting/include/Plane.h:24: error: expected ‘,’ or ‘...’ before ‘&’ token
In file included from /u/c/sissonde/computer-graphics-ray-casting/src/Plane.cpp:2:
/u/c/sissonde/computer-graphics-ray-casting/include/Ray.h:8: error: ‘Eigen’ has not been declared
/u/c/sissonde/computer-graphics-ray-casting/include/Ray.h:8: error: ISO C++ forbids declaration of ‘Vector3d’ with no type
/u/c/sissonde/computer-graphics-ray-casting/include/Ray.h:8: error: expected ‘;’ before ‘origin’
/u/c/sissonde/computer-graphics-ray-casting/include/Ray.h:12: error: ‘Eigen’ has not been declared
/u/c/sissonde/computer-graphics-ray-casting/include/Ray.h:12: error: ISO C++ forbids declaration of ‘Vector3d’ with no type
/u/c/sissonde/computer-graphics-ray-casting/include/Ray.h:12: error: expected ‘;’ before ‘direction’
/u/c/sissonde/computer-graphics-ray-casting/src/Plane.cpp:5: error: ‘Eigen’ has not been declared
/u/c/sissonde/computer-graphics-ray-casting/src/Plane.cpp:5: error: expected ‘,’ or ‘...’ before ‘&’ token
make[2]: *** [CMakeFiles/raycasting.dir/src/Plane.cpp.o] Error 1
make[1]: *** [CMakeFiles/raycasting.dir/all] Error 2
make: *** [all] Error 2

I found a page on the Eigen home folder about using it in projects with cmake but didn't find anything relevant. Did I initialize something wrong?

In simulate_bayer_mosaic.h it says to use the BGGR bayer pattern but the assignment says to use GBRG so which patter should we use?