Terrible results with ResizeImage() - PB 4.4 beta 2 Win x86

[srod]

Download test image - 48x48 bmp

Code: Select all

  LoadImage(1, "test.bmp")
  ResizeImage(1, 96, 96)
If OpenWindow(0, 100, 200, 400, 400, "", #PB_Window_SystemMenu | #PB_Window_MinimizeGadget | #PB_Window_MaximizeGadget|#PB_Window_ScreenCentered|#PB_Window_SizeGadget)

  Repeat
    EventID = WaitWindowEvent()
    Select EventID
      Case #WM_PAINT
        If StartDrawing(WindowOutput(0))
          DrawImage(ImageID(1), 20, 40) 
          StopDrawing()
        EndIf

      Case #PB_Event_CloseWindow
        quit = 1

    EndSelect

  Until quit = 1
  
EndIf

When I run the code (with the image supplied) under PB 4.31 I get nice results. With PB 4.4 - terrible! Even worse if you resize the image to be smaller than the original 48x48 !

With little experience of the new 2d-drawing and image libs I thought I'd solicit a few opinions before contemplating a bug report - always a good option!

Can anyone confirm this? Anyone know what might be causing it?

Thanks.

[srod]

REMOVED.

[milan1612]

Sorry for not being able to help you, but you should definitely read this blog entry
by freak where he addresses the changes being made in the new 2D Drawing library.

http://www.purebasic.fr/blog/?p=196

[srod]

Yes I read that some time ago.

[eriansa]

Okay it is a 32-bit image and the alpha channel is kicking in - forgot about that!

When copied to a 24-bit image it all works much better! Is there a drawing / resize flag in the new libs which effectively allow a resize which does not affect the alpha-channel?

See also http://www.purebasic.fr/english/viewtop ... =4&t=38694

24bit in pb4.40 is 3 times slower than 32bit was in pb 4.31.

[Fred]

Please don't mix everything, this has nothing to do with the subject. 32 bits display wasn't working in PB 4.31.

[eriansa]

Hi fred,

can you please run this benchmark with 4.31 vs 4.40 and then I promise I will stop bothering you with this issue

Code: Select all

; from the manual :
; If 'Depth' is omitted Or set To #PB_Image_DisplayFormat, the image format is taken from the desktop format. 
; Valid 'Depth' values can be: 1, 2, 4, 8, 16, 24 And 32 Bits. 
; When manipulating true colors formats, And want save back the modifications without color information loss, it's advised to use the 24 or 32 bits values. 
; If the images are only used For displaying on the screen, #PB_Image_DisplayFormat will provide faster performances.
#Count=100
#NrOfDepts=8
#Width=800
#Height=600
Dim arrDepths.b(#NrOfDepts-1)
Dim arrSecs.d(#NrOfDepts-1)
arrDepths(0)=1:arrDepths(1)=2:arrDepths(2)=4:arrDepths(3)=8:arrDepths(4)=16:arrDepths(5)=24:arrDepths(6)=32:arrDepths(7)=#PB_Image_DisplayFormat

;Resize test
If QueryPerformanceFrequency_(@qFreq.q)
  For d=0 To #NrOfDepts-1
    QueryPerformanceCounter_(@qTimeA.q) 
    For i=1 To #Count
      CreateImage(0,#Width,#Height, arrDepths(d)) ;32bits
      ResizeImage(0,#Width/10,#Height/110)
      FreeImage(0)
    Next  
    QueryPerformanceCounter_(@qTimeZ.q)
    arrSecs(d)=(qTimeZ-qTimeA)/qFreq
  Next 
  szLabel.s="Resize..."+Chr(13)
  For d=0 To #NrOfDepts-1
    szLabel.s=szLabel+Str(arrDepths(d))+ "bits : "+StrD(arrSecs(d))+" secs"+Chr(13)
  Next  
EndIf

;SetgadgetState test"
If OpenWindow(0,0,0,#Width,#Height,"test")
  For d=0 To #NrOfDepts-1
    QueryPerformanceCounter_(@qTimeA.q)
    CreateImage(0,#Width,#Height, arrDepths(d))
    ImageGadget(0, 0, 0, #Width, #Height, ImageID(0)) 
    For i=1 To #Count
      SetGadgetState(0, ImageID(0))
    Next 
    FreeGadget(0)
    FreeImage(0)
    QueryPerformanceCounter_(@qTimeZ.q)
    arrSecs(d)=(qTimeZ-qTimeA)/qFreq
  Next 
  szLabel.s=szLabel+"SetGadgetState..."+Chr(13)
  For d=0 To #NrOfDepts-1
    szLabel.s=szLabel+Str(arrDepths(d))+ "bits : "+StrD(arrSecs(d))+" secs"+Chr(13)
  Next  
  MessageRequester("Result "+Str(#PB_Compiler_Version),szLabel)
EndIf

[freak]

eriansa:
wrong topic.

srod:
Windows cannot do a smooth resize with alpha channel, so we had to use a custom routine. 24bit images still use the API, hence the difference. Wether or not the quality difference qualifies as a bug i don't know. Your image gives me a "Page not found", so i cannot even check it right now.

[Rescator]

Windows cannot do a smooth resize with alpha channel

Is this true for Vista and Win7 as well? I kinda imagined that the new double buffering that Vista+ does ensured that flickering and the likes was a thing of the past. (unless people turn off Aero in which case it's XP behavior I believe?)

[freak]

> Is this true for Vista and Win7 as well? I kinda imagined that the new double buffering that Vista+ does ensured that flickering and the likes was a thing of the past.

Yes. Its not about flickering. The StretchBlt() API just erases all alpha information in smooth mode, and AlphaBlend() which can resize as well always uses the non-smooth mode. Wether MS is keeping this behavior for backward compatibility or because they do not think GDI it worth fixing because GDI+ is there i don't know. GDI and alphachannel just don't go well together.

[Rescator]

Hmm! Good point, if I where to guess it's probably due to GDI+ being preferred to them.
I guess doing GDI+ variants for Windows 5.x+ would be too messy. (two new buildtrees just due to that right? plus a need for a choice in the IDE/Compiler for 9x and NT5 target compiling *sigh*)

[srod]

@Freak : my apologies, under closer inspection, the bmp in question is a 4-bit bitmap. PB 4.31 creates a 32-bitmap to house the image and it resizes fine. PB 4.4 preserves the 4-bits per pixel (before and after the resize) and it is with PB 4.4 that the problem arises (unless I take steps to convert to 24-bit).

Is ResizeImage() not appropriate for 4-bit images under PB 4.4?

(I have uploaded the image again so the above link should work.)

[Mistrel]

The link is still broken here, srod.

[srod]

Strange - I definitely uploaded the image again. I remember testing it!

I reckon my hosting service installed a backup because there were recent problems with the server.

I've uploaded the image again.

[Mistrel]

I don't know if this is relevant but it seems like a different bug. When I use the #PB_Image_DisplayFormat flag with LoadImage the picture turns purple.