I need some code that will ask names of 2 input files(windows explorer), then compare pixel by pixel. Files must have same specs. If value is same, move pixel to new output file. If value is >, move the > pixel over.
At end save output file as newfile.png
New file must have EXACTLY same specs as input files. These are gray scale images, no color.
Haven’t tried anything . Need help. I’m not coder
Related
I want to create a secondary capture DICOM file as per the requirements.
I created one, but the image( pixel data in the tag 7FE0 0010 ) looks distorted. I am reading a JPEG image using Gdiplus::Bitmap and using API ::LockBits and 'btmpData.Scan0' to get the pixel data. The same is inserted into the pixel data tag - 7FE0,0010. But while viewing the same in a DICOM viewer, it is coming as distorted. The dicom tags Rows, Columns, PlannarConfiguration are updated properly. BitsAllocated, BitsStored and HighBit are given values 8,8 and 7 respectively.
While goggling I came to know that, instead of RGB format, the bits might be in the order BGR. Hence I tried to switch the bits in the place 'B' and 'R'.
But still the issue exist. Could anybody help me ?
Apparently you forgot to take into account Stride support from GDI+. An image being much more explicit than 1000 words here is what I mean:, the actual full article being here.
I read dicom images with ITK using itk::ImageSeriesReader and itk::GDCMImageIO after reading i flip the images with itk::FlipImageFilter (to get right orientation of the images) and convert the itkImageData to vtkImageData using itk::ImageToVTKImageFilter. I visualization images with VTK using vtkResliceImageViewer in QVTKWidget2.
I set:
(vtkResliceImageViewer)m_imageViewer[i]->SetColorWindow(windowWidthTAGvalue[0028|1051]);
(vtkResliceImageViewer)m_imageViewer[i]->SetColorLevel(windowCenterTAGvalue[0028|1050]);
and i set following blac&white LookUpTable:
vtkLookupTable* lutbw = vtkLookupTable::New();
lutbw->SetTableRange(0,1000);
lutbw->SetSaturationRange(0,0);
lutbw->SetHueRange(0,0);
lutbw->SetValueRange(0,1);
lutbw->Build();
And images shown into my software compared with the same images shown into other software are much darker, i can not get the same effect as other DICOM viewers
My software images are right other software image is left also when i use some other LookUpTable in this example Flow i can not get the same effect (2nd row images) my image on right is much darker then other.
What i am missing why my images are darker what can i do? i was research a lot into dicom and ikt/vtk can not find good solution any help is appreciate.
Please check the values for Rescale Slope (0028,1053) and Rescale Intercept(0028,1052) and apply the Modality LUT transformation before applying the Window level.
Your dataset may have VOI LUT Function (0028,1056) attribute value of "SIGMOID" instead of "LINEAR".
I extracted the image data from one of your DICOM file (brain_009.dcm) and looked at the histogram of the image data. It looks like, the minimum value stored in the image is 0 and maximum value is 960 regardless of interpreting the data is signed or unsigned. Also, the Window Width (0028:1051) has an invalid value of “0” and you cannot use that for displaying the image.
So your default display could set the Window Width to 960 and Window Center to half the window width plus the minimum value.
I have a really weird error,
so I'm trying to read a pgm image by loading its pixel values into an array, I was able to correctly read in its version, height, width, and maximum possible pixel value. However, when I start reading the pixel values, I always get 0. (I know it's not zero because I can read it using imread in matlab, but have to implement it in c++, plus I couldn't use the opencv library so..)
And besides, when I read the pgm file in like NotePad++, the first few lines are good representing the information about this image ,how ever, the actual pixel values are not readable. I'm wondering if I need some sort of parsing to read a pgm image? Its version is p5.
Thanks!
You must have an assignment to solve as there is no sane reason implementing a PGM reader otherwise.
There are two different PGM formats: ASCII and binary. You seem to expect an ASCII PGM but the one you have is binary.
Have a look at the specs: http://netpbm.sourceforge.net/doc/pgm.html
It says:
/1. A "magic number" for identifying the file type. A pgm image's
magic number is the two characters "P5".
[…]
/9. A raster of Height rows, in order from top to bottom. Each row
consists of Width gray values, in order from left to right. Each gray
value is a number from 0 through Maxval, with 0 being black and Maxval
being white. Each gray value is represented in pure binary by either
1 or 2 bytes. If the Maxval is less than 256, it is 1 byte.
Otherwise, it is 2 bytes. The most significant byte is first.
The format you are expecting is described further down below as the Plain PGM format. Its magic number is "P2".
I have a freshly compiled libjpeg version 9 and tried running jpegtran.exe in command line with the arguments:
.\jpegtran.exe -rotate 180 -outfile test_output1.jpg testimg.jpg
testimg.jpg: test_output1.jpg:
As you can see it does rotate the image but it clips it and it's not put together correctly. The usage.txt file that comes with the package isn't totally up to date because I had to use the -outfile switch instead of what it says:
jpegtran uses a command line syntax similar to cjpeg or djpeg. On
Unix-like systems, you say:
jpegtran [switches] [inputfile] >outputfile
On most non-Unix systems, you say:
jpegtran [switches] inputfile outputfile
where both the input and output files are JPEG
files.
To specify the coded JPEG representation used in the output file,
jpegtran accepts a subset of the switches recognized by cjpeg:
-optimize Perform optimization of entropy encoding parameters.
-progressive Create progressive JPEG file.
-arithmetic Use arithmetic coding.
-restart N Emit a JPEG restart marker every N MCU rows, or every N MCU blocks if "B" is attached to the number.
-scans file Use the scan script given in the specified text file.
See the previous discussion of cjpeg for more details about these
switches. If you specify none of these switches, you get a plain
baseline-JPEG output file. The quality setting and so forth are
determined by the input file.
The image can be losslessly transformed by giving one of these
switches:
-flip horizontal Mirror image horizontally (left-right).
-flip vertical Mirror image vertically (top-bottom).
-rotate 90 Rotate image 90 degrees clockwise.
-rotate 180 Rotate image 180 degrees.
-rotate 270 Rotate image 270 degrees clockwise (or 90 ccw).
-transpose Transpose image (across UL-to-LR axis).
-transverse Transverse transpose (across UR-to-LL axis).
Oddly enough (or maybe not), if I execute .\jpegtran.exe -rotate 180 -outfile test_output2.jpg test_output1.jpg I get the original image back without any clipping issues. It's flipping the clipped parts but just not lining it up right with the rest of the image.
test_output2.jpg:
I get the same result by executing jpegtran.exe -rotate 90 twice.
Also, I tried it on a larger .jpg file which resulted in the same issue but the file size was 18KB smaller for the output. I imagine the issue is related to this.
Edit - I also found this blurb which seems to describe the problem:
jpegtran's default behavior when transforming an odd-size image is
designed to preserve exact reversibility and mathematical consistency
of the transformation set. As stated, transpose is able to flip the
entire image area. Horizontal mirroring leaves any partial iMCU
column at the right edge untouched, but is able to flip all rows of
the image. Similarly, vertical mirroring leaves any partial iMCU row
at the bottom edge untouched, but is able to flip all columns. The
other transforms can be built up as sequences of transpose and flip
operations; for consistency, their actions on edge pixels are defined
to be the same as the end result of the corresponding
transpose-and-flip sequence.
The -trim switch works, if you can call it that, and trims out the disorganized data but the image is smaller and lost data.
test_output5.jpg:
Adding the -perfect switch which supposedly stops the above from happening results in this: transformation is not perfect for output and no image.
So is it not possible to losslessly rotate a .jpg? I could, myself, go into paint and reconstruct the original image by simply moving the edge lines into their correct place. Is there a method to do this within libjpeg?
A lossless rotation works with whole DCT blocks contained within the JPEG file. These blocks are always 8x8 or 16x16 pixels (depending on the compression downsampling settings). The file contains a width and height so the extra pixels can be thrown away when the image is decoded, but there's no way to move the clipping from the right/bottom edge to the left/top edge. The software is doing the best it can with an impossible problem.
As you've discovered the way around this problem is to make the width and height evenly divisible by 16. You'll find that images from cameras for example will have this property.
can anyone tell me the correct method to use the getOutputValue function in the following link? Also, how does the author get the 2nd and 3rd image from the code.
http://www.codeproject.com/Articles/385658/Multidimensional-Discrete-Wavelet-Transform
Thanks
Okay, usage:
I haven't tried it yet, but from what I get you simply call getOutputValue() to get one result. The parameter is a vector containing the "coordinates" (based on the number of dimensions in your input).
Images:
In this example, the author obviously used the image data as the discrete values, e.g. a black pixel would be 0 and a white pixel would be 255 with all other shades of grey being inbetween (default 8 bit grayscale image).
He then used the output signal/result to recreate a image (i.e. interpret the values as pixels once again).