Jump to content
UltravioletPhotography

IRG processing


bostwickenator

Recommended Posts

bostwickenator

I was looking through all the various IRG processing examples:

* https://www.flickr.c...ong/4960099202/

* https://www.flickr.c...57641782172204/

* http://www.ultravioletphotography.com/content/index.php/topic/2846-flying-with-tiffen-12

 

I've determined what the community desperately needs is yet another software toolchain :tongue: . So here you go. It's web based so you don't need to set anything up.

IRGweb: http://irgweb.s3-web....amazonaws.com/

Link to comment
Herman1705

Thanks for this.

Made some mods in the Python code to make adjustment of selective coloring of the reds afterwards. The # code is the original code. The corrections on irMat seem not necessary.

 

------------8<--------------

 

irMat = np.float32(ir)

 

gMat = np.float32(green)

# gMat = cv2.subtract(gMat,irMat*.8)

gMat = cv2.subtract(gMat,irMat)

 

 

rMat = np.float32(red)

# rMat = cv2.subtract(rMat,irMat+.65)

rMat = cv2.subtract(rMat,irMat)

 

# output = cv2.normalize(cv2.merge((gMat, rMat, irMat*.6)), None, 255, 0, cv2.NORM_MINMAX, cv2.CV_8UC1)

output = cv2.normalize(cv2.merge((gMat, rMat, irMat)), None, 255, 0, cv2.NORM_MINMAX, cv2.CV_8UC1)

 

-------------------8<-------------------------

Link to comment
Herman1705

With GNU Octave, which is free:

 

function rgb2irg(varargin)

%rgb2irg;

I = imread('your_file_path_goes_here\foo.TIF');

[x,map]=rgb2ind(I);

[r,g,b] = ind2rgb(x,map);

Rnew = b;

Gnew = r-b;

Bnew = g-b;

[x,map]=rgb2ind(Rnew,Gnew,Bnew);

J = ind2rgb(x,map);

imwrite(J,'your_file_path_goes_here\bar.TIF');

disp('done');

end

Link to comment
Andy Perrin

Octave is free but so buggy I refuse to use or recommend it. Better to stick with Python.

 

Also, no need to do ind2rgb and rgb2ind. The tiff already has the components separated. It is best to convert to double first because otherwise you risk loss of precision if you do any multiplication or division on the components.

 

I would recommend something like,

 

function rgb2irg(varargin)

%rgb2irg;

I = imread('your_file_path_goes_here\foo.TIF');

r = double(I(:,:,1));

g = double(I(:,:,2));

b = double(I(:,:,3));

J = zeros(size(I));

J(:,:,1) = b;

J(:,:,2) = r-b;

J(:,:,3) = g-b;

J = uint16(J);

imwrite(J,'your_file_path_goes_here\bar.TIF');

disp('done');

end

Link to comment
I only know C. I can't generate images with it (I think). It would have been so helpful when I programmed the Mandelbrot fractal... I did a bit of Matlab, but I don't remember it very well.
Link to comment
Andy Perrin
Stefano, it’s pretty easy to do graphics with OpenGL in C. Tell me if you want some example code.
Link to comment
Andy Perrin
Haha, I'm not going to debug your code. I help students debug code for a living. Example code is one thing, unpaid work is another!
Link to comment

Haha, I'm not going to debug your code. I help students debug code for a living. Example code is one thing, unpaid work is another!

I don't want to make you work for me, just tell me how I could generate an image with my code (if you want). The code already works.
Link to comment
bostwickenator

Hey guys I'm going to be looking into patching up the math this weekend and adding some configuration files. Feel free to submit pull requests if you have contributions.

 

# output = cv2.normalize(cv2.merge((gMat, rMat, irMat*.6)), None, 255, 0, cv2.NORM_MINMAX, cv2.CV_8UC1)

output = cv2.normalize(cv2.merge((gMat, rMat, irMat)), None, 255, 0, cv2.NORM_MINMAX, cv2.CV_8UC1)

As for these matrix multiplications they are intentional to compensate for the dynamic range differences in that channels. This will all be configurable and based on gamma shortly anyway :)

Link to comment
Doesn't work. I browse and select an image TIF of the desired type, click LOAD then nothing happens?
Link to comment
A jpg version of my "test TIF" worked -- well, not really. "Worked" as in a file is loaded and something is done with it, but the outcome is nonsensical and Firefox complains about a script "slowing down your computer". in fact, it is almost hung.
Link to comment

Here is what the output looks like;

 

canvas.jpg

 

Not what I consider acceptable ... this was with default settings.

 

My usual processing of this class of images leads to the following,

 

B201905126984.jpg

Link to comment
bostwickenator

https://developer.mo...ats/Image_types has a decently up to date list. I would recommend PNG. Unfortunately the canvas APIs in JS do not support 16 bit color depth. I might have to include additional 3rd party image loading code at some point.

Very cool worked with a jpeg image I uploaded.

What file types are supported in browser?

 

There are definitely some trade offs to running this in a browser. It's not the most computationally efficient environment and without going into too much detail I'm not utilizing multicore CPUs at this point. Apologies about those warning messages, I'll update the page to warn that may happen. You will definitely have to tweak the settings to generate a reasonable output. I would suggest working with a small version of the image say 600x400 to tune the settings if your browser struggles with larger images. TIFF images might not work at all right now I was testing with PNGs and I was using Google Chrome. I should say if you have a established processing flow I'm not expecting this will compete with it, at least not yet. For me building this is about lowering the barrier to entry.

A jpg version of my "test TIF" worked -- well, not really. "Worked" as in a file is loaded and something is done with it, but the outcome is nonsensical and Firefox complains about a script "slowing down your computer". in fact, it is almost hung.

 

Here is an example setup

post-303-0-63948400-1591620524.png

post-303-0-72082100-1591620553.png

{

"version": 1,

"fractionInfraredInBlue": 0.58,

"gammaOfInfraredInBlue": 1.5,

"fractionGreenInGreen": 1,

"gammaOfGreenInGreen": 1.35,

"fractionInfraredInGreen": 0,

"gammaOfInfraredInGreen": 1.41,

"fractionRedInRed": 1,

"gammaOfRedInRed": 0.88,

"fractionInfraredInRed": 0,

"gammaOfInfraredInRed": 1.5

}

Link to comment
OK, I thought you had some magic ingredients at work behind the curtains. I'll stick to my usual processing routines for now, at least until the worst bugs or artefacts have been rectified.
Link to comment
bostwickenator
Huh, interesting I wasn't thinking about it before but now I wonder if I could train a neural network to tweak the settings. That would be much much slower though.
Link to comment
Andy Perrin

Image subtraction should never be attempted on JPEG-compressed images, at least if you want good results. The reason is that part of the JPEG algorithm involves DOWNSAMPLING the chromaticity information:

post-94-0-20018100-1591630312.png

 

The results are eventually turned back into RGB, but the damage is done -- the colors now are correlated across more than 1 pixel (usually 2x2 blocks). This is then further degraded by the lossy compression using discrete cosine transform. When you subtract individual pixels, the resulting losses and round-off lead to incorrect/degraded results, which are much more visible in the manipulated image than if you use an undamaged TIFF file.

 

Use TIFFs.

--

 

Below I have run my own subtraction code on the same image, first on the original TIFF data, then on a JPG saved from that TIFF (I did it on the full image but cropped afterwards so the view is slightly shifted). Both images were saved as JPG before uploading to the board of course. The JPG quality setting used was 8, and it was not progressive.

 

Much of the posterization damage to the sky is actually from subtracting 8-bit numbers vs. 16 bit, but the trees have lost resolution to to the JPGing beforehand. Even though both are subsequently converted to JPG (at the same settings), only the one that was converted before processing shows major damage:

 

Processing done on TIFF, JPG conversion after processing (1-1 crop):

post-94-0-31787800-1591632042.jpg

 

Processing done on JPG and saved as JPG with same settings as above (and before processing), also 1-1 crop:

Note dramatic loss of resolution, visible especially in the trees and in the antenna!

post-94-0-83181400-1591632095.jpg

Link to comment
bostwickenator
Agreed, PNG is also a lossless alternative which has good cross browser support which is why I recommend it here. TIFF is still the gold standard but I'll have to do more work to support that.
Link to comment
Andy Perrin
TIFF is usually just uncompressed RGB values (sometimes with lossless compression also) and usually 16bit (although I don't think it's required). PNG is usually lossless, but only 16bit/channel should be used in image subtraction applications. 8bit/channel is not enough.
Link to comment
bostwickenator
Like I said TIFF is the gold standard however from a pragmatic position 8bit/channel is working reasonably well in my examples. But extended colour depth is high up my feature list as well.
Link to comment

Please sign in to comment

You will be able to leave a comment after signing in



Sign In Now
×
×
  • Create New...