PureBasic Forums - English

Posted: **Mon Jul 25, 2005 3:39 am**

ResizeImage()
ResizeMovie()
DrawImage()

(and more?)

All lack a Keep aspect resize flag/mode/option.

ResizeImage() #PB_Image_KeepAspect could be used with the existing [mode] argument.

ResizeMovie() #PB_Movie_KeepAspect would need a [flag] argument added.

DrawImage() #PB_Draw_KeepAspect would need a [flag] argument added.

It is very easy to add, here is a example keep aspect capable resize
(that is able to scale up AND down while keeping original aspect)

Select a program/window,
then press the "Print Screen" key,
and look at the aspect resized image in the test window.

Code: Select all

;This is the aparently magic yet so easy way to do it
;I use this to get the proper width/height for image resizing and movie resizing etc.
Procedure AspectSize(source_w,source_h,*dest_w,*dest_h)
Protected aspect.f,w.l,h.l,width.l,height.l
 If source_w=0 Or source_h=0 Or *dest_w=0 Or *dest_h=0 : ProcedureReturn : EndIf

 width=PeekL(*dest_w)
 height=PeekL(*dest_h)

 aspect.f=source_w/source_h

 w.l=width
 h.l=width/aspect
 If h>height
  w=height*aspect
  h=height
 EndIf

 PokeL(*dest_w,w)
 PokeL(*dest_h,h)
EndProcedure


;Example use code grabbed from a recent forum post, and slightly modified.
If OpenWindow(0,300,30,600,400,#PB_Window_SystemMenu,"test")
  UseJPEGImageEncoder()
  CreateGadgetList(WindowID())
   ImageGadget(0,0,0,WindowWidth(),WindowHeight(),0)
  Repeat
    ev=WindowEvent()
    If GetAsyncKeyState_(#VK_SNAPSHOT)<>0 : If ev=0 : Delay(1) : EndIf
      GetWindowRect_(GetForegroundWindow_(),win.RECT)
      x=win\left : y=win\top : w=win\right-win\left : h=win\bottom-win\top
      dm.DEVMODE : srcDC=CreateDC_("DISPLAY","","",dm) : trgDC=CreateCompatibleDC_(srcDC)
      bm=CreateCompatibleBitmap_(srcDC,w,h) : SelectObject_(trgDC,bm) : BitBlt_(trgDC,0,0,w,h,srcDC,x,y,#SRCCOPY)
      DeleteDC_(trgDC) : ReleaseDC_(bm,srcDC) : CreateImage(0,w,h)
      StartDrawing(ImageOutput()) : DrawImage(bm,0,0) : StopDrawing()
      w_new.l=WindowWidth()
      h_new.l=WindowHeight()
      AspectSize(w,h,@w_new,@h_new)
      ResizeImage(0,w_new,h_new)
      SetGadgetState(0,UseImage(0))
      Delay(500)
    EndIf
  Until ev=#PB_EventCloseWindow
EndIf

Altough I don't mind using my own procedures,
I think many would love a simple flag to do it instead

(not to mention a "little" faster when implemented in ASM

Posted: **Mon Jul 25, 2005 3:45 am**

Ditto! I would really find it useful to have this feature in any gadget that it would pertain too!

Posted: **Mon Jul 25, 2005 3:58 am**

Hmm! Just thought of another thing!
Not sure if the KeepAspect should autocenter the image or not by default.
So maybe a #PB_Image_KeepAspect|#PB_Image_CenterAspect
and maybe a #PB_Movie_KeepAspect|#PB_Movie_CenterAspect (I'm sure the media player peeps here would love that

and a #PB_Draw_KeepAspect|#PB_Draw_CenterAspect

Or maybe #PB_......._KeepAspect and #PB_......_CenterAspect
could be mutualy exclusive rather than complimentary?

This is the 3rd or 4th time I've had to resize something
while still keeping the original aspect and have it centered.
And each time I've pondered, why doesn't PB have something so basic? (pun intended

Here is a example of my own aspect and centering for my media player (hey it's a modern variation of the "Hello World" beginner code

Warning, the following code is unfinished. Esp. the aspect ratio part
that will eventually handle anamorphic "detection" and more.
But it shows once again how "easy" it is to center a aspect resized image/video.

Code: Select all

Procedure VideoResize()
 If m_height=0 Or m_width=0 : ProcedureReturn : EndIf
 If anamorphic
  aspect.f=(m_width*1.33333333)/m_height
 Else
  aspect.f=m_width/m_height
 EndIf

 If aspect<1.0 : aspect=1.33333333 : EndIf

 width=WindowWidth()
 height=WindowHeight()
 new_width.l=width
 new_height.l=width/aspect
 If new_height>height
  new_width=height*aspect
  new_height=height
 EndIf
 
 ;This is the centering code
 If new_width<>width
  x.l=(width-new_width)/2
 EndIf
 If new_height<>height
  y.l=(height-new_height)/2
 EndIf

 ResizeMovie(x,y,new_width,new_height)
EndProcedure

Posted: **Fri Dec 23, 2005 8:33 am**

I agree that a #PB_Image_KeepAspect flag for ResizeImage() would be great!

And more importantly: could the resized image KEEP the same image number?
It's too confusing (and not intuitive) to do "ResizeImage(0,w,h)" and then no
longer be able to refer to this image by 0 anymore... why does it have to use
another number or ID? Doesn't make sense.

Posted: **Fri Dec 23, 2005 11:32 am**

PB wrote:And more importantly: could the resized image KEEP the same image number?
It's too confusing (and not intuitive) to do "ResizeImage(0,w,h)" and then no
longer be able to refer to this image by 0 anymore... why does it have to use
another number or ID? Doesn't make sense.

What do you mean exactly ? It should work like that no ?

Posted: **Fri Dec 23, 2005 12:18 pm**

Let me do some more tests and get back to you.

Posted: **Fri Dec 23, 2005 5:58 pm**

@PB
hmm...

no problems here:

Code: Select all

If OpenWindow(0, 0, 0, 640, 480, #PB_Window_SystemMenu | #PB_Window_ScreenCentered, "test") And CreateGadgetList(WindowID(0)) And CreateImage(0, 240, 160)
  
  If StartDrawing(ImageOutput())
    Box(0, 0, 240, 160, RGB(255, 0, 0))
    StopDrawing()
  EndIf
  ImageGadget(0, 0, 0, 240, 160, UseImage(0))
  Debug ImageID()
  Delay(3000)
  
  ResizeImage(0, 480, 320)
  If StartDrawing(ImageOutput())
    Box(0, 0, 480, 320, RGB(0, 255, 0))
    StopDrawing()
  EndIf
  ImageGadget(0, 0, 0, 480, 320, UseImage(0))
  Debug ImageID()
  Delay(3000)
  
  ResizeImage(0, 320, 240)
  If StartDrawing(ImageOutput())
    Box(0, 0, 320, 240, RGB(0, 0, 255))
    StopDrawing()
  EndIf
  ImageGadget(0, 0, 0, 320, 240, UseImage(0))
  Debug ImageID()
  Delay(3000)
  
EndIf

End

the 0 doesnt change, but the number of ImageID().

c ya,
nco2k

Posted: **Fri Dec 23, 2005 11:34 pm**

ImageID() returns the system identifier, that's why it's change (because a new image is created).

Posted: **Sat Dec 24, 2005 2:39 am**

I can't recreate it now. Doesn't matter I guess.

Posted: **Thu Jan 19, 2006 10:19 am**

Please keep in mind that "keeping aspectratio" while resizing is a quite tricky task.

Most, well, almost all known avis on the www do have a PAR of 1:1.

Whats PAR? PAR is the "pixel"-aspekt ratio.

Where an AR (as most people know this shortcut) is defined in the prof. videoworld as DAR, means displayaspectratio.

The displayaspectratio (DAR) is the final state when the video is shown in the correct state. Like on a TV set (4:3) or a Beamer device (4:3 or 16:9).

For example a PAL DVD gots 720x576 pixels, in that state its NOT 4:3, cause 720/576 wouldnt result as 1,3333, means 4:3. So whats wrong?
DVDs are meant to be played back via a DVD SAP device and here if a TV is the ouput target, then the TV scales these 720x576 by using the PAR to bring square pixels to their quadra pixels state.

So 720 is the width at squarepixels. The PAL TV gots a PAR of 128/117 or better said 768/702. 768 is the full TV supporting PAL digital resolution. 702px are the effective ITU BT601 pixelarea. Means 768 are WITHIN these 702 pixels, so thats why the resulting PAL TV PAR is 768/702 which equals to 128/117.

So in case of a DVD the formula is ...

720*PAR x 576 = 787,692*(128/117) x 576

Thats why a 720px ITU BT601 stream is NOT! 4:3 (or better said 1.3333:1)

The real DAR of 720x576 is ...

787,692*(128/117) / 576 = 1,368:1 !

I made a software (using PB btw

) which does resizings for avisynth purposes by respecting the ITU BT601 compilancy.

http://forum.doom9.org/showthread.php?t ... t=paranoia

Posted: **Thu Jan 19, 2006 10:40 am**

great work Incredible !

BHH
ps. Will you release the source code ?

Posted: **Thu Jan 19, 2006 10:44 am**

Correct! But you are forgetting that the images and the video as far as PB is concerned is allready in 1:1 pixel aspect ratio.

Images mostly are as all images originates from a PC anyway,
I doubt many would use JPG's directly from their digital cameras,
nor would people use raw frames from movies.

And as far as the movie playback goes.
PB uses the system codecs, these has allready (or should) have corrected any pixel aspects to 1:1.

That just leaves image aspect, if you show a image or video at original size there is no need to worry.
But if you decide to scale it to a bigger or smaller size, unless you scale both vertical and horizontal the same amount, you will need to correct the image/video aspect.
Typical use would be showing a image or video in full screen.

Remember the codec has allready adjusted the pixel aspect.
(and actualy most video, be it DivX/XVid or WMV etc. are usualy in 1:1 pixel aspect,
and if they are not the codec does that at playback time.
And as far as images goes, I can't remember ever seeing a image on a PC that was not 1:1 pixel aspect.

I do know that raw mpeg (DVD etc) tend to be not square (1:1) pixel aspect.
Then again, I doubt many would play back dvd or raw mpeg thru their PB programs or games

My reason for suggesting the image aspect resize is that it would allow a bit faster but a lot easier resizing while keeping image aspect.

Besides, those who where to resize TU BT601 stream frames should hopefully know the standards well enough and know not to use image aspect flag, it's that simple really.

Thanks for pitching PureBasic on doom9 though, very cool

The non 1:1 pixel aspects is annoying though, it's a relic of the past that the industry refuse to let go of.

Myself I prefer 1:1 pixel aspect and 2:1 image aspect in 24bit or 32bit RGB progressive, why the industry decided to go for non square pixels and 16:9 is sad indeed.
And I find it creepy that NTSC is still in use, *shakes head in disgust*
Oh and whomever invented interlace should be beaten up along with the NTSC inventor.

Posted: **Thu Jan 19, 2006 11:44 am**

And as far as the movie playback goes.
PB uses the system codecs, these has allready (or should) have corrected any pixel aspects to 1:1.

Are you shure?
"imho" the decoder engine just passes through the PAR/DAR/SAR information in the frameserved bistream. Its "imho" on the application if the incoming pixel state will be corrected to quadrapixels (1:1) using resizing routines or system routines (overlay, VMR, etc.).

Images mostly are as all images originates from a PC anyway,
I doubt many would use JPG's directly from their digital cameras,
nor would people use raw frames from movies.

Well

.... I started coding in PB as I wanted to code apps for videoediting purposes. And if someone starts using this fantastic PB as it comes with already declared Movie routines, then a non-par 1:1 input should be taken in into account.
90% of all videoediting open source apps. do come along in C/C++ like the developers at doom9.org also do use.
Since I released there some of my apps and told that I use that "Purebasic" or when I posted some approaches in there where that easy PB syntax was shown ... many PMs reached me where I have been asked "Wow, PB seems to be great! More infos please"

but thats just btw.

Then again, I doubt many would play back dvd or raw mpeg thru their PB programs or games

Well I do see PB as a possibility to make programming of such apps MUCH more easier and so why not taken into account high industry specs like in this "video" case. So these steps are little ones which do make PB even more and more interesting for prof. programmers

The non 1:1 pixel aspects is annoying though, it's a relic of the past that the industry refuse to let go of.

Nooooooooooooooo!

Non PAR 1:1 is like a compression factor!
And The DVD SAPs do provide a signal of 13.5 Mhz (ITU!), where a TV Set works at 14,769 (these are PAL examples). also here 14,769/13.5 = almost PAL_TV_PAR = 128/117

If you watch the tread about my appl at doom9 you do see that even mp4 encoding cracks now tend to use non PAR 1:1 like in mpeg1/2 to force even more movieinformations getting into the same amount of bits

PAL PAR 1:1 at 625Lines at 14,769Mhz = 768x576
PAL PAR TV (128/117) at 625Lines at 13,5Mhz = 702x576

702x576 padded to 720x576 will result in significant less bits as if 768x576 would be used! The little stretching-interpolation from 702to768 is not that recognisable (for shure not on a 625 Lines TV set).

The HDTV technology is here more accurate (thats what do you meant by old relicts in case of TV PAR right?

)

A clean 1.777778:1 DAR is fully coded into a PAR 1:1 .... 1280x720p or a 1920x1080i mpeg stream. BUT for really enjoying the gain of such detailness "they" have to gave such a stream a sufficient bitrate!
And thats what almost never is beeing done on for example SAT HDTV broadcastings. Big image size but in relation to "that" imagesize less quality.

HDTV in the quality purpose of broadcastings will be acceptable in mybe 5 years imho --- but thats just my taste, nothing to be said in general

Thanks for pitching PureBasic on doom9 though, very cool

Not only there, Im active on some other boards too where I do clearly say that PB is my tool to go for. (kvcd, germanDoom9, etc.)

My "to do list" btw for PB is creating some useful UserlIbs like for example ...

A complete DirectShow based capture library as almost all newer capturedvices do use Dshow drivers which makes AviCap useless (imho) for common SAA7134 Philips chip based capturecards (pinnacle, terratec, etc).
Sources are available in the Platform SDK. I already ahd a look at it.
So using the Routines in the Amcap example for building a wrapper could be "an approach".

Or Useful imageprocessing routines as avialable in the XVID project for example: SSE based YV12 to RGB32 and vice versa for example, although such a library then will be forced to be released under the GPL as XVID sources are released under the GPL.

The big "fish" would be a wrapper to libavcodec!!
That Lib gots everything to de and encode to almost all common video and audioformats WITHOUT having drivers in the system installed as all routines are within libavcodec.
I already startet a thread in here (or was it at the german PB board? hmmmm) but no response as I need some assistance.

PureBasic Forums - English

#PB_Image_KeepAspect and #PB_Movie_KeepAspect etc.

#PB_Image_KeepAspect and #PB_Movie_KeepAspect etc.

Re: #PB_Image_KeepAspect and #PB_Movie_KeepAspect etc.

Re: #PB_Image_KeepAspect and #PB_Movie_KeepAspect etc.

Re: #PB_Image_KeepAspect and #PB_Movie_KeepAspect etc.