Tema: "Standard" demosiac test raws?

Hello everyone. I've been following the discussions here with much excitement. I want to try an edge-directed demosiacing script derived from a filter for video deinterlacing which by coincidence does a very good job at upsizing photos 2x-4x. Could someone direct me to downloads of the most common raw files for testing demosiacing quality with a lot of info near nyquist? I see often one with a tree and a building on the other side of a road and one with a girl in a pink sweater, but I cant find the raws.
_______________________________________________
_______________________________________________
In the mean time here is a D700 ISO6400 test image, click to se full size. WARNING you may get adult ads.


_______________________________________________
_______________________________________________
The bad news: Morie is visible and the process is only 8 bits. The good news: No visable aliasing and very smooth texture, quite film-like.

The demosiacing script takes raw bayer images like 'dcraw -d' as input. Perhaps a special dcraw build that could filter color artefacts in the document mode would improve the moire situation. Maybe jdc would have some idea?

Since I dislike alaising I didnt like AFD so I will personally try to use this script in my workflow. However if anyone knows if the modified dcraws can do simmilar interpolation I'd like to hear about it.

I still don't understand why most of the recent demosaicing literature doesn't deal with aliasing since it's basic for a pleasant output. Most of them uses high-order pixel interpolation or the the Hamilton-Adams method, which suffer from serious overshooted pixels in fine details and diagonals. The only reason I've found is that it's much easier to achieve a higher PSNR with HOI or H/A+EECI, and thus the author gains greater notoriety.

It's possible to avoid zipper artifacts with a local demosaicing without limiting the interpolated pixel value within its nearest directional neighbors (like AHD does, which introduces false colours), without softening the output and without renouncing to directional filtering when necessary for avoiding moire.

Just an example (AFD is well known in this forum and LMMSE is a representative algorithm in the spirit of LPA-ICI, HPHD, GBD, etcetera. "-q 0" is my current algorithm):

Iniciado por Lassus

I still don't understand why most of the recent demosaicing literature doesn't deal with aliasing since it's basic for a pleasant output. Most of them uses high-order pixel interpolation or the the Hamilton-Adams method, which suffer from serious overshooted pixels in fine details and diagonals. The only reason I've found is that it's much easier to achieve a higher PSNR with HOI or H/A+EECI, and thus the author gains greater notoriety.

Sorry, what is HOI and what is EECI?

What camera for the above example?

Your result is very nice.

Thanks for the compliment, Emil, but it's not deserved. The right part of the window (which doesn't appear on the image) has some moire. Although I have better results than the following I'm not able to find a way for interpolating it correctly. It's the hardest file I've ever tried:



http://raw.fotosite.pl/download-Pent...4/IMGP7093.PEF

How does AMaZE deal with this RAW? It will be a relief for me knowing that this window can be perfectly demosaiced.

If you don't mind I would like to answer your questions here since I think they are of general interest and I will send you some more information privately in a while:

HOI is the acronym of High-Order Interpolation (at pixel level) which takes advantadge of the spectral correlation of the neighbor pixels in one direction up to five pixel distance from the guessed value. The best method I've found is the one proposed by Li and Randhawa in their Color Filter Array Demosaicking Using High-Order Interpolation Techniques With a Weighted Median Filter for Sharp Color Edge Preservation reference:

Código:

N=CLIP((23*pix[-u][1]+23*pix[-w][1]+pix[-y][1]+pix[+u][1]+8*(pix[-v][c]-pix[-x][c])+40*(pix[0][c]-pix[-v][c]))/48);
E=CLIP((23*pix[+1][1]+23*pix[+3][1]+pix[+5][1]+pix[-1][1]+8*(pix[+2][c]-pix[+4][c])+40*(pix[0][c]-pix[+2][c]))/48);
S=CLIP((23*pix[+u][1]+23*pix[+w][1]+pix[+y][1]+pix[-u][1]+8*(pix[+v][c]-pix[+x][c])+40*(pix[0][c]-pix[+v][c]))/48);
W=CLIP((23*pix[-1][1]+23*pix[-3][1]+pix[-5][1]+pix[+1][1]+8*(pix[-2][c]-pix[-4][c])+40*(pix[0][c]-pix[-2][c]))/48);

For those not used to dcraw notation, "CLIP" limits the guessed value between 0 and 65535, "c" are the red/blue channel depending on the location, and "u","v","w","x","y" are the inmediately 1st,2nd,3rd,4th,5th upper pixels respectively. After that they use a weighted median for smoothing overshoted pixels but I've never coded it to see how it works.

This method is really nice (color rendition is near perfection) in the absence of a sharp edge and also seems to increase accutance in high ISO shots, giving a pleasant, colorless noise but it fails noticeably in some obvious regions.



For comparison purposes, the widely used Hamilton-Adams method (in fact I think it's the one chosen both in LMMSE and in AFD) is as follows:

Código:

N=CLIP(pix[-u][1]+(pix[0][c]-pix[-v][c])/2);
E=CLIP(pix[+1][1]+(pix[0][c]-pix[+2][c])/2);
S=CLIP(pix[+u][1]+(pix[0][c]-pix[+v][c])/2);
W=CLIP(pix[-1][1]+(pix[0][c]-pix[-2][c])/2);

I find more accurate working with ratios but it's also more tricky when strong signal variations are present. I know there is an old reference from Lukac that also uses ratios, but I've never had access to it. Basically I use a mix between H/A and my adaptive ratios. I've tried an adaptive method with HOI in low frequency regions but time consumption was too high and the improvements didn't worth it.

Just for curiosity I believe the new demosaicing in Lightroom Beta 3 is also using ratios with any kind of limit based on the following picture (the output of my algorithm is "AR + H/A" -without the color degradation near the letters introduced by the GIF-):



I supppose those dots are a non reported bug they will fix sooner or later. Adobe team, if you are reading this, my algorithm is on sale.

On the other side EECI is a kind of refinement partially coded by Paul Lee some time ago. The reference is the following:

http://www3.ntu.edu.sg/home5/CHAN0069/JEI013003.pdf

It's used by some algorithms (vg. LMMSE) in order to increase PSNR and reduce false colors.

Best regards,

-Luis

Iniciado por Lassus

Thanks for the compliment, Emil, but it's not deserved. The right part of the window (which doesn't appear on the image) has some moire. Although I have better results than the following I'm not able to find a way for interpolating it correctly. It's the hardest file I've ever tried:


How does AMaZE deal with this RAW? It will be a relief for me knowing that this window can be perfectly demosaiced.

I'll see what I can do, though it may take me a while to get around to it.

HOI is the acronym of High-Order Interpolation (at pixel level) which takes advantadge of the spectral correlation of the neighbor pixels in one direction up to five pixel distance from the guessed value. The best method I've found is the one proposed by Li and Randhawa in their Color Filter Array Demosaicking Using High-Order Interpolation Techniques With a Weighted Median Filter for Sharp Color Edge Preservation reference:

This method is really nice (color rendition is near perfection) in the absence of a sharp edge and also seems to increase accutance in high ISO shots, giving a pleasant, colorless noise but it fails noticeably in some obvious regions.

Do you have a copy of this article? I couldn't seem to find it online.

For comparison purposes, the widely used Hamilton-Adams method (in fact I think it's the one chosen both in LMMSE and in AFD) is as follows:

I find more accurate working with ratios but it's also more tricky when strong signal variations are present. I know there is an old reference from Lukac that also uses ratios, but I've never had access to it.

Send me an email so I have your address.

Basically I use a mix between H/A and my adaptive ratios. I've tried an adaptive method with HOI in low frequency regions but time consumption was too high and the improvements didn't worth it.

I looked at ratios a bit and it didn't seem promising, but I didn't spend much time on it. Looked to me that color differences had less high-frequency variation, and so would be more robust to interpolation.

On the other side EECI is a kind of refinement partially coded by Paul Lee some time ago. The reference is the following:

http://www3.ntu.edu.sg/home5/CHAN0069/JEI013003.pdf

It's used by some algorithms (vg. LMMSE) in order to increase PSNR and reduce false colors.

-Luis

Paul and I investigated this a bit for AMaZE, but it didn't seem worth the trouble.

Differences in the Kodak CD set are not as clear as in real world images. In fact PSNR is about 0.3 dB lower with ratios than with H/A and about 0.6 dB lower than with HOI. But visual quality in normal photographys is another story:



http://raw.fotosite.pl/download-Niko...k/DSC_0934.NEF

I will try to code this weekend the weighted median Li and Randhawa are proposing.

Iniciado por ejmartin

Send me an email so I have your address.

Didn't you receive my email yesterday?

______

I have edited the GIF in order to add the method AHD is using in dcraw: H/A limited by the north/south green pixels if interpolation is in vertical direction or east/west pixels if it is in horizontal direction.
_______________________________________________
_______________________________________________
If you don't mind, Mark, I will use this topic for testing my algorithms (admins, the topic on WPG could be closed and moved to the old topics subforum). I will post some samples and executables each time I consider I've made a significatively improvement.

For those who want to try the last revision of my algorithms I have compiled an executable with the following options:

-q 0: My main algorithm. I'm still looking for a name.
-q 1: FDD. Almost as good as AHD, almost as fast as bi-linear. Actually the "almost" referring to the speed is more accurate than the other , anyhow its efficiency is really really high).
-q 99: A very early alpha release of the new directional filtering kernel I'm working on. At this moment i've only written specific code for large homogeus low frequency regions (like the girl with the pink sweater, the building with the two pillars or the _DSC7909.NEF file). In the rest of the images it's noticeably worse than -q 0. Just for testing purposes.
-N a b c: Experimental noise reduction. "a" and "b" are the radius and the treshold of the chrominance smoothing kernel while "c" is the treshold of the dead/hot pixel removal filter. I warn I've noticed some undesirable artifacts when using large "a" radius I need to correct.
-R a b c d: Alters the parametrization of -q 0. Defaults are a=10, b=0.75, c=0.90 and d=0.50. I do not recommend using this option.
-Y: Extracts the region we are using for the D700@25600 NR.
-I: Activates HOI when using -q 0.

"-q 0" is all the necessary for 95% of the RAWs.
"-q 0 -I -Y -N 15 575 1000" works nice with the D700@25600.

The chrominance noise reduction is slugish. Also -q 0 and -q 99 aren't a speed paradigm but they are reasonably quick when compared with the last publications at IEEE Transactions on Image Processing.

The download link: http://www.xmlog.es/files/dcraw/dcraw_09_12_22.zip (the password is "ry6;H&2Y" without the quotation marks).

Please, post here any issue experienced with -q 0.

Best regards,

-Luis

My effort:-

http://img46.imageshack.us/img46/9233/capturear.png

Fujicoly, your sample looks promising. You're getting almost none directional errors. Is it possible to know how does your algorithm work? Is it using any kind of horizontal/vertical gradients decision or on the contrary is it working with refining iterations? I'm not at home for doing a proper comparison but at first sight your results reminds me of that of Jacek Góźdź's DCB: few directional artifacts but a severe lack of color correction on edges.

If I remember correctly your RAW developer is not available for downloading yet. Could you upload other representative samples or compile an executable just for testing purposes if possible?

If your algorithm works with an H/V decision (calculating the probability whether a pixel should be interpolated in horizontal or in vertical direction -or be merged between both-) it's easy to correct the lack of color correction by changing the way the missing pixel value is guessed. However if it's performing several correction passes like DCB or it's doing the interpolation with a non-local method it may not be possible.

BR,

-Luis

May be an interesting comparison look at the edges of the neon sign.

-q 0 with dcraw build posted two posts back


AFD

Thank you Mark for posting the crop.

Those kind of saturated edges are quite problematic. Although -q 0 looks better than AFD, it still has some artifacts in the green part of the neon sign. For these cases playing with the parametrization may be useful. For example adding the "-R 10 0.75 0.0001 0.0001" option should improve the greens. There is a bug that prevents using "-R 10 0.75 0 0" which I hope to be the optimum, I will fix it tomorrow.

Best regards,

-Luis

I agree -q 0 looks better overall. The raw can be downloaded from here: http://raw.fotosite.pl/download-Cano...lek_prv_pl.CR2

For this example I used a highly modded version of DCB, I have also been working on the color problem please see the image below:-

Iniciado por Lassus

Fujicoly, your sample looks promising. You're getting almost none directional errors. Is it possible to know how does your algorithm work? Is it using any kind of horizontal/vertical gradients decision or on the contrary is it working with refining iterations? I'm not at home for doing a proper comparison but at first sight your results reminds me of that of Jacek Góźdź's DCB: few directional artifacts but a severe lack of color correction on edges.

If I remember correctly your RAW developer is not available for downloading yet. Could you upload other representative samples or compile an executable just for testing purposes if possible?

If your algorithm works with an H/V decision (calculating the probability whether a pixel should be interpolated in horizontal or in vertical direction -or be merged between both-) it's easy to correct the lack of color correction by changing the way the missing pixel value is guessed. However if it's performing several correction passes like DCB or it's doing the interpolation with a non-local method it may not be possible.

BR,

-Luis

You're right, Fujicoli, there is a significant improvement in your approach. I'm thinking about a specially designed refinement for DCB that could work nice. If I have time I will do some test during these days.

Markanini, your sample inspired me a new chrominance interpolation method. When I finish its fine tuning I will upload a new revision of my executable (sorry for the GIF quality):




I'll be three or four days since tomorrow without internet connection...

Merry Christmas to you all,

-Luis

I never planned to use AFD for non noisy images, the reason are those overshot pixels, in diagonals and saturated areas. I implemented it in pR as a fast interpolation algorithm for high ISO shots, not for general purpose interpolation. We also tried mixed interpolation, using AFD in the shadows and AHD in the rest of the image.

In my opinion, we need at least four interpolation algorithms in pR 1.0 development engine:

• One very fast RGB interpolation algorithm for non noisy images with enough quality. I believe that at this point the winner in quality/speed terms is PPG. I will reimplement it with OpenMP for the final version of pR 1.0. Anyway there are some candidates to substitute PPG, most of them from Lassus. I specially do not like the diagonals from PPG.
• One very fast RGB interpolation algorithm for high ISO shots. I have been using AFD for that. I am still waiting for AFD authors to give us permision to use AFD. Since I have not that permission I have switched to LMMSE, but it is slower (although far better that AFD). I will try to speed it up, although I believe Lassus will provide us a very fast alternative .
• One extreme quality algorithm for non noisy images. Here the winner is AMaZE.
• One extreme quality algorithm for noisy and very noisy images. Here the winner is AMaZE again.

That does not mind that pR will only allow four interpolation algorithms, I will try to give the user as much options as possible.

BR,

Iniciado por markanini

Hello everyone. I've been following the discussions here with much excitement. I want to try an edge-directed demosiacing script derived from a filter for video deinterlacing which by coincidence does a very good job at upsizing photos 2x-4x. Could someone direct me to downloads of the most common raw files for testing demosiacing quality with a lot of info near nyquist? I see often one with a tree and a building on the other side of a road and one with a girl in a pink sweater, but I cant find the raws.
_____________________________

Hi, I have been following this forum for a while and I am excited at the results everyone has been getting. Good work everyone.
I recently took a photo that has significant artefacts when demosiacing. If you are interested I can let you have a copy somehow.

Maybe we could create a patch DNG (Egon could help with that) with interesting pieces of other RAW images, they should be auto WB and converted to RGGB first but that is not a problem, anyway. That shirt of Iain looks interesting, the window of the previous samples, the girl with the orange/pink t-shirt, some piece with high ISO noise, etc. It should not be bigger than 900x900 pixels in order to be uploaded here and be fast to interpolate, and we could stablish it as the master interpolation sample for everyone here. It should be converted to sRGB with sRGB exact gamma (or 2.2 gamma, is up to us to decide) after interpolation before posting the results here. What do you think about?

Ideally one of us could create a web site to put the samples on it, with a link to the DNG, a list of the interpolation algorithms, creator contact, explanations, etc. It would be perfect if we could put the timings of all the algorithms running in the same machine (for that in ANSI-C). I would rather base the comparison in visual terms, than in terms of PSNR. I agree with Lassus PSNR it is not always the best way to compare in the real world, and I also agree that the Kodak set is not always the best image set to be used in comparison (it has already gamma and sharpening applied for example).

Other good thing about creating such a place would be to compare the results with a mouseover, the colour GIFs are very problematic for visual comparison.

For noisy samples I will put no noise reduced samples. Other comparison in the same web site could be established for NR algorithms, but we must see how the interpolation affects the noise without any further pre/postprocessing. The bottles sample has been the standard for NR here, but I agree with Emil that we should also use non Nikon images because they have the black point already substracted, and so, they gives non-zero mean values in the shadows.

BR,

That a great set of ideas. May be jdc since he already has a site? I'd be glad to test the processing time on my c2d system if someone would make a batch file.

Looks interesting, could you email me the raw please huelight@gmail.com

Thanks.

Iniciado por Iain

Hi, I have been following this forum for a while and I am excited at the results everyone has been getting. Good work everyone.
I recently took a photo that has significant artefacts when demosiacing. If you are interested I can let you have a copy somehow.

Iniciado por ManuelLlorens

One very fast RGB interpolation algorithm for non noisy images with enough quality. I believe that at this point the winner in quality/speed terms is PPG. I will reimplement it with OpenMP for the final version of pR 1.0. Anyway there are some candidates to substitute PPG, most of them from Lassus. I specially do not like the diagonals from PPG.

I think the last FDD version I sent you outperforms PPG in all cases, even in speed. Give it a try and tell me what things you would like me to improve.

Iniciado por ManuelLlorens

One very fast RGB interpolation algorithm for high ISO shots. I have been using AFD for that. I am still waiting for AFD authors to give us permision to use AFD. Since I have not that permission I have switched to LMMSE, but it is slower (although far better that AFD). I will try to speed it up, although I believe Lassus will provide us a very fast alternative .

If you wish I think WPG could fit this gap. It's a four direction always-weighted algorithm, as AFD, but it works in the Spatial Domain, has better directional gradients, has my AR-HA pixel estimation and a better chrominance interpolation method.

Iniciado por ManuelLlorens

That does not mind that pR will only allow four interpolation algorithms, I will try to give the user as much options as possible.

If finally some other algorithms are included there will be the posibility for the user to alter parametrization or I will need to use fixed values?

Iniciado por markanini

That a great set of ideas. May be jdc since he already has a site? I'd be glad to test the processing time on my c2d system if someone would make a batch file.

If Jacques doesn't mind I would like to provide the hosting for the file. I'm programming a webpage where I will upload the revisions of my executable as well as some source code with its explanation. I hope to upload it this weekend.

Iniciado por Iain

Hi, I have been following this forum for a while and I am excited at the results everyone has been getting. Good work everyone.
I recently took a photo that has significant artefacts when demosiacing. If you are interested I can let you have a copy somehow.

Welcome to the forum, Iain!

In my opinion none of our algorithms will demosaic that RAW in a proper way. Just in case, maybe those based on DCB since they also alters the bayern pattern pixel values... The problem with your image are not missguidance artifacts: neither horizontal nor vertical direction are correct. Even a 4-color interpolation or a pass of the green channel equilibration filter Manuel wrote wouldn't help on removing those false color ellipses.

As Fujicoly I'm also interested on that file. Which camera did you use? I think it will be easier for your if you could upload the RAW file to megaupload and post here the link; otherwise I will send you my e-mail privately.

Thanks,

-Luis

Iniciado por Lassus

I think the last FDD version I sent you outperforms PPG in all cases, even in speed. Give it a try and tell me what things you would like me to improve.

Ok, I will make it the default option.

Iniciado por Lassus

If you wish I think WPG could fit this gap. It's a four direction always-weighted algorithm, as AFD, but it works in the Spatial Domain, has better directional gradients, has my AR-HA pixel estimation and a better chrominance interpolation method.

Ok again!

Iniciado por Lassus

If finally some other algorithms are included there will be the posibility for the user to alter parametrization or I will need to use fixed values?

Of course, as many parameters as you want!

Iniciado por Lassus

If Jacques doesn't mind I would like to provide the hosting for the file. I'm programming a webpage where I will upload the revisions of my executable as well as some source code with its explanation. I hope to upload it this weekend.

I will contact Egon for the DNG.

Iniciado por Lassus

In my opinion none of our algorithms will demosaic that RAW in a proper way. Just in case, maybe those based on DCB since they also alters the bayern pattern pixel values... The problem with your image are not missguidance artifacts: neither horizontal nor vertical direction are correct. Even a 4-color interpolation or a pass of the green channel equilibration filter Manuel wrote wouldn't help on removing those false color ellipses.

Well, AMaZE has been designed for those cases. I will like to see that shirt interpolated with AMaZE. What is clear in that sample is that, as Emil stands, for effective aliasing suppression very big areas must be evaluated and local interpolation is useless.

BR,

More animated GIF using FDD (almost as fast as bilinear) and WPG:

Well Lassus, those images talk themselves. I will use FDD and WPG as fast default interpolation methods in pR 1.0.

BR,

Iniciado por Lassus

As Fujicoly I'm also interested on that file. Which camera did you use? I think it will be easier for your if you could upload the RAW file to megaupload and post here the link; otherwise I will send you my e-mail privately.

Thanks,

-Luis

I have emailed the file to fujicoly and if anyone else is interested I have uploaded it here:

MEGAUPLOAD - The leading online storage and file delivery service

I hope this is helpful.

The camera was the Nikon D40.

Iain, the problem with this file does not lie with the demosaicing applied; the individual RGGB channels are strongly aliased. In other words, there is moire in the recorded raw data, even before interpolating the colors, and that moire will propagate through the interpolation no matter what demosaic algorithm is applied.

Iniciado por Iain

I have emailed the file to fujicoly and if anyone else is interested I have uploaded it here:

MEGAUPLOAD - The leading online storage and file delivery service

I hope this is helpful.

The camera was the Nikon D40.

Thank you very much.

Iniciado por Lassus

How does AMaZE deal with this RAW? It will be a relief for me knowing that this window can be perfectly demosaiced.

-Luis

I had to make two revisions to AMaZE in order to get better results with this file. One borrows some ideas from Lassus to more adaptively construct chroma interpolation, the other was to implement a test for Nyquist texture in order to best direct the interpolation. I will need to test several images in order to optimize the parameters, but here is what I get:



EDIT: Image updated after slight modifications to the algorithm.

Not perfect, certainly. I did not do any CA correction, though certainly this image could use it. There are some misinterpolations in the same area as Lassus' crop (to the left of the tree trunk), they are due to the fact that AMaZE chooses to interpolate in the direction of the shadow border rather than the underlying Nyquist texture. I'm not sure one could fix that without causing problems for many other images. I may think some more about that, but perhaps I should return to noise reduction efforts which are currently in a much more primitive state.

I know the image above is unsharpened and CA uncorrected and futher more a moire example. Still as such I find a combination of "analog" smoothness and "digital" acuteness for 100% crop. Remarkable!
Lets hope 2010 will be a good year for digital imaging quality!

Iniciado por markanini

I know the image above is unsharpened and CA uncorrected and futher more a moire example. Still as such I find a combination of "analog" smoothness and "digital" acuteness for 100% crop. Remarkable!
Lets hope 2010 will be a good year for digital imaging quality!

yes, i have to agree! looks very impressive. but i guess this is due to a lighter AA-filter from the k100d and a good lens?

btw, noise reduction is certainly important, but i still think that a rude basic demosaicing-algorithm that is performing well, should be considered for alpha or beta-testing regardless of emil's future NR-work.

I've done some modifications to my algorithm. Now it's called AMML:



In the tasks list there are the following things:

-Improve 1 pixel wide 45º diagonals. I still don't know which approach I will use: detecting and reinterpolating the diagonals or applying a projection over a geometric map. The rest of the diagonals looks good enough to me with the AR method.
-Reduce the remaining artifacts along edges.
-Optimize the code in order to speed up the whole process. Do not expect miracles here...

I upload a new revision of my executable:

http://www.xmlog.es/files/dcraw/dcraw_10_01_11.zip (Pass: "fFRh&C]0" without quotation marks).

Changelog:

-The main algorithm has been improved. There is a new parametrization option inspired after exchanging ideas with Emil and some further meditation which sets the resolving strength when dealing with low frequency regions. It's set off by default.
-I have abandoned the approach used at -q 99. Therefore that algorithm is no longer included. On the contrary I have added WPG, intended to be included in pR.
-Fixed the bug which avoids setting "c", "d" and "e" -R parameters to 0.
-Code up to date with dcraw 8.99.


Usage:

-q 0: AMML rev 2. The main algorithm.
-q 1: FDD. Ultrafast, substitute of PPG.
-q 2: WPG. Speed optimization still needed in order to match AFD efficiency.
-R a b c d e: Alters the parametrization of AMML. Defaults are a=10, b=0.0, c=0.75, d=0.90 and e=0.50. "b" is the new parameter.


_____
PS: A few days ago RawTherapee finally released its source code. You can have a look here: rawtherapee

Iniciado por Lassus

I upload a new revision of my executable:

http://www.xmlog.es/files/dcraw/dcraw_11_01_10.zip (Pass: "fFRh&C]0" without quotation marks).

How can I use this dcraw version? When I try to start nothing happens.

Iniciado por Yups

How can I use this dcraw version? When I try to start nothing happens.

Yups, it should be like any other dcraw version. Isn't it working properly? You need to open a console (cmd.exe) and write the command there. For example:

Código:

dcraw -v -w -H 0 -o 2 -4 -q 0 file.dng

There is a nice tutorial done by Guillermo Luijk: GUILLERMO LUIJK >> TUTORIALS >> DCRAW TUTORIAL

BTW, I'm adapting RaFFs (Raffs | Get Raffs at SourceForge.net) so the functions can be called from a friendly (yet basic) interface:



I hope to finish as soon as posible...

luis, how are your demosaicing-experiments progressing? sorry for not having responded to your latest email. i had lots of work to finish.
hope to see hear some news from you.

regards, olaf

Lassus and I are still working on a version of AMML that will incorporate some aspects of AMaZE together with his ideas on adaptive ratios. At some point (hopefully soon) we will settle on the approach.

I have implemented a version of CA correction from AMaZE that should work well for most images (it may have some difficulty in regions of Nyquist texture). And finally I have achieved a goal I have sought for some time -- to automatically calculate the parameters for the CA correction. Best of all, it can be done over patches of the image (so long as they contain enough pixels to have good statistics), so no assumption need be made about the optical center of the lens, field curvature, etc.

Here is Oluv's CA example:

thanks for this new example. it is great so see some progress, automatic CA correction is the key for perfect images i guess. can your algorithm also deal with "assymetrical" CAs? i have lots of images where i can get rid of CAs manually on one side of the image, but they get worse on the other side. i assume this is because of OIS-lenses or if the lenses are slightly decentered.

lately i was a bit in contact with eric chan, one of the programmers of ACR and lightroom. i played much with the latest lightroom beta and i thought it was a big improvement over the previous versions. the images have a very natural rendering, noise is looking great without any pattern structure and lightroom3b finally fixed my labyrinth artefact problem i always had with my G1 files. unfortunately i discovered that this came with the cost of sharpness. especially horizontal and vertical lines are not resolved that good.
i discovered this, when i tried to convert some GF1 files and found that these also had labyrinth artefacts. so i "hacked" my G1 files and converted them as GF1. this was the result:


you can see that the "GF1 version" is sharper. i talked about this with eric and he promised that they are working on improvements, especially with reds, as these cause the most problems for lightroom's algorithm.

live is not easy. meanwhile i have a GH1, and this one has the "labyrinth effect" as i call it (eric called it green imbalance) over the entire frame, unlike my G1 which only had it in one corner. so it seems as i will never get the sharp images i am after. my biggest hope is still perfect raw and AMaZE, but i am already that impatient...

Any developments regarding aliasing and moiré?

You can load on my site my version of Dcraw (windows) with the latest version of AMaZE (Emil Martinec).

- q 3

This version is very robust to chromatic aberrations and treats aliasing (moire) to perform well.

Jacques, I would like to try your version of DCRAW incorporating the auto CA correction and AMaZE, but feel a bit lost about:
- What file exactly I have to download and from where
- What does the command line look like to achieve the goals above

Regards

Hello Guillermo

You must load the file "executable dcraw_99.exe (version 4.62)" which is on my web page Nouvelle page 1

You must also load the DLL: vcomp90.dll and put it in the same folder as dcraw_99.exe

Maybe it is also necessary to install "Microsoft Visual C + + 2008 Redistributable Package (x86)"

The command line :

for AMaZE only : -q 3
for CA only : -9 CAE

for gamma, 16 bits, white balance,Prophoto, no levels,TIF : -9 P
-9P = -w -v -o 4 -4 -T -5 4 -W

for exposure : -F 2 3 0.1 (it's your work with Manuel) : '2' exposure correction, '0.1' highlight recover, ''3' : your algorithm

ex: dcraw_99 -9 P -q 3 -9 CAE -F 2 3 0 file.raw

Emil is currently being enhanced CA_correct (), I test ..

I feel like I am a child under the feet of giants, so please be patient with me.

I have tested the CA correction using the latest version of dcraw from Jacques' website (dcraw901.exe - version 4.64)

I compared the CA corrected version to an uncorrected version using this command: -9 P -q 3 -9 CAE -F 2 3 0 file.raw and removing -9 CAE for the second conversion.

This is the result:



You can see that the red edges on the bottom and right-hand side are shifted up and to the left with the CA correction. This seems to happen at all places in the image where this flower pattern occurs. I have seen it in other images with large red areas as well.

I hope this is helpful.

-Iain