Jump to content

SearedIce

Members
  • Posts

    253
  • Joined

  • Last visited

Posts posted by SearedIce

  1. This might be nice, however there are quick and easy work-arounds.

    You could resize the PDN window so that there is some space on the left of the screen. Then, open up Windows Explorer and resize it to fit in the empty space to the left of PDN. Navigate to your images, and then just drag and drop them onto PDN to open them.

    Sometimes I do this when I have to change the levels on a whole bunch of images or edit them in some other way.

    -John

  2. You're right about the "rect"/"image" thing. I have NO idea how it got changed when I started writing this script, but it must have. CodeLab is giving me a default rectangle called "rect" now.

    Thanks sooo much for the info on the rendering process! The script runs beautifully thanks to your help!

    The default variable name that Tom gives is "rect", not "image".

    Anyway, you're right on that last point. Effects are not rendered all at once -- otherwise it would not be possible to do things like progressive rendering ("35% done"), multithreaded rendering, and clipping to a selection region.

    You should not use rect.Bottom as the bottom of the image. That rectangle defines the current rectangle that is being rendered. Paint.NET will divide the whole rendering area into 200 rectangles per logical processor (so 400 for your P4 w/ HT), and pass each one to the effect rendering function. Because of threading, multiple rectangles will be rendered in parallel, but you don't have anything that would have trouble with that (everything is self contained in your function).

    What you want is maxy = dst.Height-1.

  3. I just added a bit of debugging code right before the "dst[x,y] = PixelColor;"

    Here's what I added:

    		if (maxy < 100)
    		{
    			PixelColor.R = 255;
    			PixelColor.A = 255;
    		}
    

    The pixels before 100 have a red tint, and those after don't. I changed the 100 to 200, and the same thing was seen but for pixels before/after 200. Somehow, the maxy is being changed to something close to the y value every time the loop executes. Could this have to do with multi-threading? I'm running this on a Pentium 4 with Hyper-Threading.

  4. I forgot to mention that the opacity of the foreground color must be set to what should be the opacity of the top of the image, and the bottom of the image corresponds with the background color's opacity.

    For my trials, I am using a forecolor opacity of 255 and a backcolor opacity of 0.

    #1. It's fading...sorta. Zoomed out, it looks like it's fading just the first 50-or-so rows of pixels from opaque to transparent. Upon a closer look, it is revealed that the fade is not really a fade at all, but the alpha values go up and down quite a bit. It's entirely crazy...I cannot figure out how these results are generated. If I could figure out why it is doing this crazy stuff, I could find my problem...I think...

    #2. I will fix that. Thanks for the advice. I should have picked that up through the syntax of the for loop. That is, it loops as long as (y

    #3 I want to get my simpler alpha-ignorant algorithm to work first. I was already planning to adapt it to deal with pixels that already have an alpha value once I got the basics working. Thanks for pointing out how I might do this.

    About the image rectangle....that's just what the default is for CodeLab...I thought it was the proper way to do it. I will edit my code to make it "roi". Should I let Tom know about this?

    argh...this code is still not working...

    -John

    Three things...

    1. You didn't state what results you're getting, just that it's "not working right". So you have no idea what is wrong, but neither do I!

    2. "Maximum Y" and "Bottom" are different things. Maximum Y is Bottom-1, so you should do "maxy = image.Bottom - 1

    3. This code assumes you are working with opaque pixels. What you should do is calculate an intermediate alpha value, "a" the same way you are currently calculating PixelColor.A. Then, "PixelColor.A = (PixelColor.A * a) / 255;" (plus any type casts that are necessary). This will properly compute the new alpha for pixels whos original alpha value is not 255.

    (... and why is the rectangle named 'image' ? It should be called roi (for rectangle-of-interest))

  5. I thought I could write a simple CodeLab effect to make an image fade from fully opaque to fully transparent. I wrote the code that I think should work, but it just is not working! I have no idea what is wrong. I've looked over my code many many many times, but I cannot figure it out. Hopefully someone can point out my error and I will learn something important from it...

    Here's the code as it is 8:14 on 3/29/06:

     

    Spoiler
    
    void Render(Surface dst, Surface src, Rectangle image)
    {
    //Environment values for fore/back colors placed into variables
    ColorBgra TopColor = (ColorBgra)EnvironmentParameters.ForeColor;
    ColorBgra BottomColor = (ColorBgra)EnvironmentParameters.BackColor;
    
    //Alpha information extracted from the fore/back colors
    int TopAlpha = TopColor.A;
    int BottomAlpha = BottomColor.A;
    
    //The difference between the two alpha values is calculated
    int Difference = BottomAlpha - TopAlpha;
    
    //The height of the image is placed into a variable
    float maxy = image.Bottom;
    
    //Two variables used in the effect's loops are created
    ColorBgra PixelColor;
    float yratio;
    
    for (int y = image.Top; y < image.Bottom; y++)
    {
    	for (int x = image.Left; x < image.Right; x++)
    	{
    		//The color of the current pixel is taken from the source surface
    		PixelColor = src[x, y];
    
    		//The distance from the top of the image in ratio (percentage/100) form is found
    		yratio = (y / maxy);
    
    		//The alpha value of the color is modified to account for the distance from the top
    		PixelColor.A = (byte)(  (yratio * Difference) + TopAlpha  );
    
    		//The modified color is put onto the destination surface
    		dst[x, y] = PixelColor;
    	}
    }
    }

     

     
  6. I think he means that he could simulate saving the history by making a whole new set of layers for every version of his image. Or, if his image is only one layer, he could make invisible duplicate layers as a way to keep the older versions available. It is not worth it to do this every time you make a little change.

    I agree that the history should be saveable. I will look into the code if no one else does.

  7. Hey! I'm also an AutoCAD person! I know exactly what you mean. Every time I start PDN, I accidentally draw on the screen, then hit Escape only to find it doesn't fix the problem. Then, I hit Ctrl-Z.

    Lol....I think you're right that the first tool selected when the program starts should be the select tool.

  8. I will describe what I do to generate the problem(?), and provide screenshots.

    (Yeah, I know the images are compressed like crazy and that my Windows theme is ugly...my father insists on it...)

    •I open a photograph for editing.

    •I open the Levels dialog.

    levelsissue1.jpg

    •I adjust the Levels as I see fit. (some change must be made, however small)

    •I click OK.

    •I open the Levels dialog again.

    •I notice that there is some crazy business:

    levelsissue2.jpg

    There seems to have been some loss of color or something (see the jaggedness of the once-smooth curves). Is this supposed to happen? What does it mean? I'm worried it might be a bug of some sort, which is why I'm bringing it up.

    It's doing this with all of my photos...

    Thanks for reading,

    John

  9. If something is selected, and I hold Ctrl, and then I use the arrow keys, the selected pixels move in increments of what appears to be 10 pixels. This is great, however, it seems that while moving, it is really copying the pixels. If I use the arrow keys to move the selected area 1 pixel at a time, it actually moves the stuff that is selected. If I use Ctrl and the arrow keys, it leaves behind a copy of the selected area in its original location. I don't know if I'm making sense here, and so if you don't understand, let me know and I'll get some screenshots.

  10. Since Lenn-art says that the PNG fix was tried, this IS NOT a browser issue. You guys (along with the rest of the Firefox crowd) are just so freaking annoying. You make ridiculous assumptions and expect everything to be spoonfed to you. Lenn-art's problem is not a browser problem, and you should not have turned this thread into an IE-bashing-opportunity.

    Now, Lenn-art, I will attempt to offer useful advice.

    There are known issues with transparency in the older versions of Paint.Net. Make sure you are upgraded to version 2.6.

    If this doesn't work, I'll try to think of something else.

  11. Lol, aatwo, thanks for thinking I'm important!

    As you may have read, PDN started as a project at WSU. For one, I live on the east coast, and for two, I am still a senior in high school! I'm not an official Paint.Net developer, but I like to try to help.

    Bug reports are probably the best way to help, if you're interested.

    For some reason I doubt that Microsoft employees get to play 360 all day...lol...

  12. Also, you might be able to use SearedIce's tutorial for this. http://paintdotnet.12.forumer.com/viewtopic.php?t=1122

    Perhaps you could, but this is more useful:

    http://paintdotnet.12.forumer.com/viewtopic.php?t=983

    See my post on that thread...

    Basically, you can print any picture that is less than 8x10 to perfect size. What you have to do is open your picture and do all editing to it. Then, press Ctrl-Shift-R to resize the canvas. Resize the canvas to 8x10 inches. Then, print the image using the 8x10 mode... It should come out to be almost exactly the right size.

×
×
  • Create New...