OJODIGITAL |
|
|
|
| perfectRAW/perfectBLEND Foro para tratar todo lo relacionado con estos dos programas basados en DCRaw para el revelado de imágenes RAW y el blending de imágenes para aumentar su rango dinámico |
![]() |
| Publicidad |
|
|||
|
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): ![]() |
|
|||
|
Cita:
Sorry, what is HOI and what is EECI? What camera for the above example? Your result is very nice.
__________________
emil Última edición por ejmartin; 21-dic-2009 a las 15:38. |
|
|||
|
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); 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); 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 |
|
|||||
|
Cita:
Cita:
Cita:
Cita:
Cita:
__________________
emil |
|
|||
|
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. 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 Última edición por Lassus; 22-dic-2009 a las 14:52. Razón: Fusión automática de mensajes para prevenir autosubir post |
|
|||
|
|||
|
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 ![]() Última edición por markanini; 22-dic-2009 a las 23:13. |
|
|||
|
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:-
![]() Cita:
|
|
|||
|
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:
BR, Última edición por ManuelLlorens; 27-dic-2009 a las 23:23. |
|
|||
|
Cita:
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, Última edición por ManuelLlorens; 28-dic-2009 a las 11:53. |
|
|||
|
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.
|
|
|||
|
|||||
|
Cita:
Cita:
Cita:
Cita:
Cita:
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 |
|
|||||
|
Cita:
Cita:
![]() Cita:
Cita:
Cita:
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, |
|
|||
|
Cita:
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.
__________________
emil |
|
|||
|
Cita:
|
|
|||
|
Cita:
![]() 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.
__________________
emil Última edición por ejmartin; 01-ene-2010 a las 04:25. |
|
|||
|
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! ![]() |
|
|||
|
Cita:
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 Última edición por Lassus; 12-ene-2010 a las 03:16. |
|
|||
|
Cita:
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 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 Última edición por oluv; 04-feb-2010 a las 15:05. |
|
|||
|
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: ![]()
__________________
emil Última edición por ejmartin; 11-feb-2010 a las 05:33. |
|
|||
|
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... ![]() |
![]() |
| Marcadores |
| Herramientas | |
| Desplegado | |
|
|