Recent

Author Topic: Display problem  (Read 6008 times)

user5

  • Sr. Member
  • ****
  • Posts: 357
Display problem
« on: March 05, 2015, 12:06:15 am »

    This is rather hard and lengthly to explain and maybe even harder to comphrehend so in advance I understand if no one wants to tackle it. Before I mention the problem that I have, I'd like to detail some background info. On my form I have a display window which contains a TImage into which my program loads bmps but because of various prior processes, the graphic image on any given bmp won't always be in the same place in that bmp. Sometimes it will be at the top and sometimes nearer the bottom and my program has no way of knowing beforehand where that image will be but I still need to display it centered in the TImage.

    Since the background of the bmp will always be white, my solution was to make Image6.height := 0 and Image6.top := the bottom of my display window and then to gradually increase Image6.height and gradually decrease Image6.top, all the while scanning across the bmp until a pixel other than white is found. At that point, the bmp will be centered in the display window.

    This technique works well and gives a very desirable and dramatic sense of motion as the bmp rises from the bottom until it's centered but if the user moves part of the display window offscreen while all of this is happening then the part of the window that's offscreen will be black, I suppose because the TImage is being stretched while it's offscreen.

    What I did to correct that, of course, was to have the program automatically move the form to the top left corner of the screen while the bmp is being loaded and then to return it to its former position after the loading.

    The problem with this is that the user might find it irritating to have the form moving around on its own, as I do, though I love the way the bmp rises into view.

    Any suggestions for a better way to center bmp images?
   

taazz

  • Hero Member
  • *****
  • Posts: 5368
Re: Display problem
« Reply #1 on: March 05, 2015, 12:32:32 am »
although I understand the problem and the solution is to force a full redraw after the motion ends, I would like to have all that ina easily compilable sample application to see where things go wrong exactly.

Oh, your assumption about the "TImage being stretched while of screen" is wrong. It is far safer to assume that because the window portion is of screen it never draws anything there and becomes black which is weird since the default behavior in windows is to become copy what ever the screen have when the window painted while moving aka transparent or no paint at all.
Good judgement is the result of experience … Experience is the result of bad judgement.

OS : Windows 7 64 bit
Laz: Lazarus 1.4.4 FPC 2.6.4 i386-win32-win32/win64

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Display problem
« Reply #2 on: March 05, 2015, 08:47:50 pm »
The program currently moves the active form to the top left corner and disables that form while the bmp or png is loading so that the user doesn't have the chance to move any portion of it offscreen. This may be something that I'll just have to live with.

Right after I sent my last note it occurred to me that I should have used the term "expanding" rather than "stretching" since nothing is being stretched. The TImage is expanded outward and moved up during loading. Your suggestion to see something compilable was interesting and I'll give some thought to that. I could possibly attach some screen captures or even an .mpg movie to my next message to more clearly show what is happening. Thanks for responding!

User137

  • Hero Member
  • *****
  • Posts: 1791
    • Nxpascal home
Re: Display problem
« Reply #3 on: March 06, 2015, 12:55:02 am »
Source code might help the most.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Display problem
« Reply #4 on: March 06, 2015, 04:57:50 am »
    Success! Problem solved! Horray instead of horror! The reason my graphics were volatile and being messed up while they were offscreen was because the object inspector option AlphaBlend was set to "false" but I set it to "true" and now everything is fine.

    I noticed that everything runs slower when AlphaBlend is true so for some things the program will be temporarily set to false, but it all works out good. This also means that I can dispense with having the form move to the top left corner and all other related nonsense. Thanks again for responding.

marcov

  • Administrator
  • Hero Member
  • *
  • Posts: 11453
  • FPC developer.
Re: Display problem
« Reply #5 on: March 06, 2015, 09:55:54 am »
Logically you would scan the image (in code) till you had proper bounds, and use .copyrect or so to copy the relevant data to another image for display.

IOW make a difference between originally image and the portion you display.

If it is not an one off problem, but do a lot with images, scaling etc, opengl might be a solution.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Display problem
« Reply #6 on: March 08, 2015, 09:20:11 am »
    Yes marcov, I think I see what you're saying; load the image and scan once it to find out where it is on the graphic background and then use that info to display it in the center of the window.

    I like the current method because it adds some nice movement and animation to my program though using AlphaBlend to keep offscreen portions of the form from going black slows that animation down. I wonder if one of the other object inspector options would
accomplish that task without slowing the program down. Will look into that. Thanx!

User137

  • Hero Member
  • *****
  • Posts: 1791
    • Nxpascal home
Re: Display problem
« Reply #7 on: March 08, 2015, 11:15:46 pm »
Quote
On my form I have a display window which contains a TImage into which my program loads bmps but because of various prior processes, the graphic image on any given bmp won't always be in the same place in that bmp. Sometimes it will be at the top and sometimes nearer the bottom and my program has no way of knowing beforehand where that image will be but I still need to display it centered in the TImage.
Why does it have no way of knowing where the TImage needs to move to? What makes it so secret that it can't be saved in a variable when created?

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Display problem
« Reply #8 on: March 09, 2015, 01:26:12 pm »
    I'm using a technique that does change the TImage's height and vertical position but the issue here isn't just the TImage but also the vertical position of the graphic image on the bmp INSIDE the TImage. It's hard to explain but the program I'm working on will load different sizes of bmps into one TImage and each of those bmps will contain a black waveform on a white transparent background and each waveform may be anywhere on that bmp.

    It may be at the top or it may be at the bottom and the bmp might be anywhere from 200 to 500 pixels in height but it still has to be centered in the display window. Not only are these different wave forms made from sound tracks with greatly varying volume levels but they also end up being cleaned and stretched by the program to provide some nice sound spike groups.

    I'm a good programmer but I think only Bill Gates could get one useful variable from all that. That's easier said than done but the point is to get the job done nicely somehow and I do that. In this case the display window can't be any more than 93 pixels in height and without some kind of checking the image might not even be seen if the bmp just happens to be say, 500 pixels in height with its waveform at the bottom of the bmp.

    I think marcov knew exactly what I was talking about because he suggested scanning the bmp ONCE to find out where the image is but instead my program scans the image a number of times while expanding the height of the TImage until the image is centered. This process gives the illusion of animation as the waveform rises to the top of the window.

    You can test this for yourself; Just load a bmp that's about 400 pixels in height that has an image in the middle of near the bottom of that bmp into a TImage that's only about 75 pixels in height and then raise the top handle of that TImage. You won't even see it at first until it rises into view. The top of the TImage may be end up near the top of the form but it doesn't matter because the bmp or png is transparent and you only see the image.

    I don't think the mere mechanics of the source code would illustrate it any better in this instance. It's the principle behind the code that's really important. I didn't mean to be so wordy about this but I love talking about Lazarus, Delphi and Pascal and I love the program that I'm working on.

    I've tried to attach a screenshot of the program's display window for perusal.

User137

  • Hero Member
  • *****
  • Posts: 1791
    • Nxpascal home
Re: Display problem
« Reply #9 on: March 09, 2015, 02:11:38 pm »
I think it would help alot if you explained what the purpose of the program is, and especially source code might help. You already know how to scan image with Canvas.Pixels[] (or Canvas.Colors[]) property, and you yourself know what to look for in the images, we don't. This waveform is part of bigger picture.. what kind of picture? I see the wave part has white background, so can you look for white pixels, or does the other background have white too to make it complicated? What is the background anyway, can it be ocean view with palmtrees for instance?

You also didn't specify why the waveform has to be scanned from that image, why can't it be saved separately? Why can there be different kind of images where there is such a waveform in random location, it is out of my imagination range  :P  Animation is a completely separate topic also, leave it out of scanning the image issue, they shouldn't be done at the same time anyway.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Display problem
« Reply #10 on: March 11, 2015, 09:30:57 pm »

    Thank you so much for your response, user137. I'm sorry that my last note was so long but I get carried away sometimes. I tried to attach a larger .bmp picture of the whole form to that note but the forum rules wouldn't let me attach it because it was too big. However, I made another larger screen capture of the entire form in .gif format and it came out much smaller so I have attached it to this note. I hope it shows okay. I'm not sure how to answer some of your questions and in a way it seems as if we're comparing apples and oranges but the issue is moot anyway because my original problem involved darkening of the waveform window when that window was offscreen and that problem is solved.

    My program is an .mpg documentary and presentation movie maker that allows the user to combine .avi and .mpg movies, animated .gif movies, still images, text, .wav and .mp3 music or voice soundtracks into one .mpg movie. It allows the user to put a multiple number of movies anywhere inside of the movie being made. The attached picture shows the main activity window but the program also has other forms.

    The skyline area in the colored box is the default capture area of 240x180 but the program also features a larger custom capture area of up to 528x386. This program also has a unique option which allows the user to make a custom animated cartoon virtual person who can look like the user or anyone else and who speaks in synchronization with that person's voice. The mouth of the cartoon character moves as the voice track plays and the eyes can blink.

    The cartoon person can smile, smirk, frown etc. The waveform shown in the striped window in this case is a voice track and the blue vertical lines are editable sync markers created automatically by the program after it analyzes the voice track. The waveform IS created by the program from a voice track and then displayed.

    You are the first person on this forum to ask me what the program does so I thought that I would oblige since I never tire of talking about my work. This program is more than 2/3 finished but much remains to be done and I would consider having a co-author if anyone is interested. Might look good on someone's resume.

    Again, I'm sorry that this note was even longer than the last one but my enthusiasm always gets me into trouble. This was all made possible by LAZARUS! I love Lazarus.

mm7

  • Full Member
  • ***
  • Posts: 193
  • PDP-11 RSX Pascal, Turbo Pascal, Delphi, Lazarus
Re: Display problem
« Reply #11 on: March 11, 2015, 10:05:21 pm »
user5, I agree with marcov on working with the bitmap image in memory to find out a rectangle around a fragment you interested in, then make output of this fragment to screen (or another Image) with CopyRect.
If you like an animation, you can write a cycle that gradually decreases source rectangle from the original full image to the fragment size and copies it multiple times with some delay. This should be fast and smooth.

user5

  • Sr. Member
  • ****
  • Posts: 357
Re: Display problem
« Reply #12 on: March 12, 2015, 05:56:44 pm »
    mm7, you and marcov have given me some good ideas and good stuff to think about and I'll see what I can do. I do need to speed things up a bit. Got some big fish to fry. Thanks for taking the time to help.

 

TinyPortal © 2005-2018