Jump to content

zarathoustra

Members
  • Posts

    89
  • Joined

  • Last visited

Everything posted by zarathoustra

  1. Manual Color You can download Manual color now. (Updated 2010-02-15) This plugin lets you colorize a selection with the color of your choice. Quick steps: 1) Open a black and white picture. (Or turn a color picture into black and white) 2) make a selection with the lasso. 3) Apply Color -> Manual color with the color of your choice. Color Inpainting You can download Color Inpainting now. (Updated 2010-02-15) This plugin colors gray areas in a picture where colors are only known in few parts of the picture. If your picture is already fully colored, applying this filter will NOT change anything. Quick steps: 1) Open a color picture. 2) Make a rectangle selection in the middle of the picture. 3) Apply Adjustement -> Black and white to the selection 4) Deselect. 5) Apply this filter (Color -> Color inpainting) It will color the area where you removed it. The plugin implements "Fast Image and Video Colorization Using Chrominance Blending", Yatziv and Sapiro, 2006. Using together These two plugins are ment to be used together in real life scenario. It attempts to solve the problem of colorizing a completely black and white picture semi-automatically. Quick steps: 1) Open your black and white picture 2) Apply Adjustement -> Black and white, to make sure it's really black and white. Info: A black and white looking JPEG picture is not necessarily REALLY black and white. JPEG uses the fact your eyes are not too sensible to colors to seamlessly alter them. Then, a pixel that was a real shade of gray, after being saved in JPEG format, can become something that looks like a shade of gray but isn't. In this case, this plugin will detect such pixels as colored, and will not color them. 3) Using the lasso and the "Manual color" plugin, colorize some parts of the picture. 4) Apply "Color inpainting" to color automatically the rest of the picture. 5) If you are not satisfied with the result, cancel, colorize more parts of the picture, and go to 4). Known issues Luminosity is not preserved.
  2. I think i somewhat understand the second paper. you have the L in HSL and the H and S only on some part of the picture 1) you take the gradients out of the L layer 2) then you fill out the blanks on other layers such that: everything is smooth, and the gradients on these layers are as close as possible as those on the L layers. I don't know if i missed something in the big picture. I don't think i could implement that one though. I understand nothing about partial differential equations, "poisson" is only the french for "fish" for me, and i can't imagine a fish equation or a fish solver! lol
  3. Do you know this paper? http://www.math.ucla.edu/~lvese/PAPERS/01211536.pdf I didn't try to understand it, but at first glance, it looks good. Also I always thought this paper would make a nice plugin for coloring black and white picture. http://www.ima.umn.edu/preprints/may2004/1979.pdf
  4. Yea, i know, i was asking for PDN 4. Thanks for the answer
  5. I could implement it. It's a pretty simple technique actually. Pretty impressive if you consider the complexity/quality ratio. Using a fourrier transform, you get the phase/magnitude of the prototype window (blue mask) and of the repair window You keep the phase of your repair windows as is, and for magnitude you take the min of prototype and repair windows. Then you do the inverse transform to go back to spatial domain. And you keep the new pixel values only where your black mask is. And then you start again. Progressively, the texture replaces the black mask. The papers are here: http://citeseerx.ist.psu.edu/viewdoc/su ... .1.56.3169 http://citeseerx.ist.psu.edu/viewdoc/su ... .1.53.5591 Don't let the wording fool you. They talk about projection onto convex sets, but it's really just intellectual masturbation... For the the fourrier transforms there are libs. This one looks nice: http://www.fftw.org/
  6. Hey, This question is mainly for rick, but i guess if anyone has informations it's ok. I've long thought about the limitation of effect plugins. I think, the actual system is pretty good when it's all about applying a function to a picture. But there's a whole kind of things that require interactivity that don't belong to that category, as it's not just about setting some parameters. In this category, i've seen pyrochild's smudge plugin, and there are probably others existing, and even more which could be created. I can't stop thinking that such plugins would be better as tools, rather than open a new plugin window with the picture and let you edit the picture in this plugin window. Another case would be a very simple inpainting technique i read about. It requires the users to draw 3 masks on the picture, then it can do it's job. (picture attached) I think it would be best as a tool, like you select the tool, then you can choose some mode in the tool's toolbar and work with it. So I wanted to know if you had any plan to support some kind of tool plugin, in PDN 4?
  7. lol The guy explains that the projects started at washington state university and that Microsoft hired the two developers of PDN. :?: That you continue to improve the application. That PDN is cool and has lots of things. THE END
  8. Looks like this plugin is just a wrapper for dcraw.exe, you need to have it in some pdn directory
  9. @rick: I don't think gzip is more difficult or easier to implement than most other algorithms. @???: I think BWT based compressors have a greater potential for compression ratios than LZMA. BZip2 only fails because of legal issues, the guy switched from arithmetic coding to huffman coding because he feared patents (arithmetic coding can encode symbols on 1.2 bits when huffman can only encode symbols on an integer number of bits). But there was/is other compressors using that algorithms that works far better. In my remembrance, most other compressors that beat it, are russian compressors having fun at trying to crush every bit of data (like 12 hour and 2Go ram for compressing your 2MB file, well, probably exagerated, but not so much....) using several advanced statistical modeling techniques and blending probalities (predicting the input is what compression is all about after all), etc... But if you're seeking compression ratio, you'd better do something like: expected data specific transform -> BTW -> range coding For the legal issues, the bzip guy, didn't feel that range coding was ok (legally), but wikipedia says arithmetic coding isn't, and range coding is, which is retard because it's the same algo, from the point of view of someone having a clue (it's only a precision issue), but patents are usually retards, so, that might be true, ... or not... he didn't take the risk...
  10. Yes, right, what i was thinking about would be different, i see what you mean now
  11. hmm, i don't know that paper (didn't find), but those guys seems to be in computer vision/artificial intelligence. So, it can make a lot of sense for them to consider the spatial dimensions, because in a picture with 2 red balls, a red ball on the left is not the same object than a red ball in the right of the picture, so you'd like to have 2 different clusters to identify 2 different objects. But, in your case, in the end, you're just turning a 16 million colors in a 20 colors image, you never exploit the information that the right palm tree in not the same thing than the left palm tree for example (considering your sample picture). So, having more than 1 cluster for the palm trees doesn't help. Right now, you get 6 dimensions centroids, but then, you only use 4 dimensions of each centroid to get the color of the cluster, the 2 other spatial dimensions are discarded. I might be wrong, but i really think, you're clustering on too many dimensions here.
  12. Also, why do you cluster in the {x, y, r, g, b, a} space, instead of the {r, g, b, a} space? I can't think of a case where it would make a big difference. By droping the x and y dimensions, you'll just don't get 2 clusters of nearly identical colors, just because they are spatialy far from each others. If you do it in the {r, g, b, a} space, you can simplify your distance function, but you can also reduce the number of points to cluster, since there are usualy less different colors than pixel count in a picture. You could also use a tolerance, such that you blend 2 colors instead of adding a new one, if they are too close. This could significantly reduce the number of points to cluster.
  13. void Render(Surface dst, Surface src, Rectangle rect) { double increment = 255.0 / (double) src.Width; for (int x = rect.Left; x < rect.Right; x++) { byte alpha = (byte) Math.Round(x * increment); for (int y = rect.Top; y < rect.Bottom; y++) { ColorBgra CurrentPixel = src[x,y]; CurrentPixel.A = alpha; dst[x,y] = CurrentPixel; } } } Edit: in codelab, rather than in pseudocode.
  14. Yea, neil's effect is slow, it also gives the feeling that he's breaking the progress bar, if you look carefully. But he had no choice here, he has to heavily analyze the picture for doing this (doing k-means to classify pixels), and it mostly makes sense in the init step. I checked his code, and it's just a case where computing the function to apply to the image is slow as hell whereas applying the function is fast. Actually, in his case, it would make sence to have a progress bar for initialization, and no progress bar for applying the effect. (not saying that progress bar should be removed) Nevertheless, his plugin is pretty cool and the effect really nice, and has good quality. Do you know already, how you are going to fix that ?
  15. Repro: 1) open PDN 2) open segment image plugin 3) cancel effect immedialty 4) drop a png picture in pdn 5) click "open" 6) wait and get the error. Status: Repros everytime for me. Complete guess: PDN might have a race condition somewhere around that, cause neil's nice effect takes ages in the initialization step of the effect.
  16. you still can start the app and open a picture with command line. > PaintDotNet.exe picture.jpg
  17. Solved! I had some dlls with platform target set to x86 a while ago, and now i'm on x64. So the dlls wouldn't load.
  18. Same problem again Except now i can't see what dll is missing.
  19. yes, it's another class library. no, i forgot to copy the dll. :oops: Actually just this would create the problem. MpegParser mpegParser = null; Edit: Problem fixed. Thanks.
  20. No. Did that already fixed such a problem for you? I'd like to understand what's going on. I mean, even if mpegparser fails on this stream, it should throw an exception. But there's nothing.
  21. I got this code: protected override Document OnLoad(Stream subFile) { try { MpegParser mpegParser = new MpegParser(subFile); return Document.FromImage(new Bitmap(500, 500)); } catch (Exception e) { MessageBox.Show(e.ToString(), "SubFileType OnLoad exception"); return null; } } I set 3 break points on curly braces for opening the methods's body, try, and catch. When I comment the MpegParser line, it does what expected (a 500x500 empty picture and breaks). When I don't comment that line, PDN says "The file could not be found" and it doesn't even break on my breakpoints. I thought maybe MpegParser would throw an exception, so i catched all exceptions, but nothing get catched. So I'm a bit confused. Any idea ?
×
×
  • Create New...