TheSaint

When not doing CD covers I tend to use PNG, but my recollection is that the embedded artwork in an MP3 or FLAC file needs to be JPG. I also use JPG for the folder image, as in Folder.jpg. which is what Windows or devices use. I can't say I have noticed that color issue when I use GDI+. The problem for me with an otherwise great program like IrfanView, is the quality when saving. If I go for 100%, I often end up with a file size multiple times bigger than the original, which I don't want and concerns me. So in the past I have had to play around with the degree of quality to get a better all-round result. The concern for me though, is a whether it is a bit like the old MP3 editors, that would convert to WAV so you could edit, and then reconvert back to MP3, having reduced the quality of the MP3 even more in the process. With GDI+ I get a decent size file without any obvious or major difference in size or look, reduction or enlargement amounts aside. I have it set to the value recommended, which is 7 I think.

@KaFu Thanks. Not sure why that did not turn up in my search here the other day ... or maybe it did and I didn't browse far enough. Anyway, I've downloaded it to have a bit of a play when I get the time. Normally, in the past, I have always used the free IrfanView for most of my image needs, often via its command-line, but I mostly try to avoid any kind of dependency these days, if I can. I could have just edited with that, as I have done so many times in the past. One issue for me though, has always been what JPG quality to save at, and GDIPlus simplifies that for me. That is especially the case, where the source file is not very large, and so not much quality to play around with, and so quite possibly I will end up with some even poorer looking image, without there seeming much I can do about that. I mostly care with my CD covers, because they are displayed big on my TV, and any faults can be glaring.

Nice to know I have inspired you two masterminds. I am looking forward to checking these out. BIG THANKS. I'm not sure about that, but certainly the major flaw of my code, is that you only see the end result image, so it is somewhat of a painstaking process of trial and error. The only real known is the final required 600x600 pixel size for the CD artwork that I embed in my music files. Admittedly most of the time I can source good enough CD covers from Discogs (primarily). It is only the odd rare instance when I need to crop, and even rarer to rotate. Trial and error guesses though, can waste a lot of time, so once again BIG THANKS.

Thanks for that @UEZ, you are the GDI+ Master, and I shall indeed check it out and look into the crop side of it too.

BIG THANKS to @UEZ for his code, which I adapted, plus adding some of my own. See his post here. I spent quite a while trying to come up with something simple to include in a program of mine. The examples in the Help file didn't quite do it for me, some very complex. Here's an image I needed to rotate by 1 degree right, and then trim and resize, for embedding into my FLAC and MP3 files for that album. The image was sourced from eBay, as alas Discogs let me down. Admittedly the album title wasn't very helpful, and there are two other volumes, though I only have the first one. Anyway, I have provided the image, so you can test and play around with it. #include <GDIPlus.au3> ; BIG THANKS to UEZ ; I modified his example from - https://www.autoitscript.com/forum/topic/155932-gdiplus-need-help-with-rotating-an-image/?do=findComment&comment=1127106 Global $hBackbuffer, $hBitmap, $hBitmap_Scaled, $hClone, $hCoverBitmap, $hCoverGC, $hCoverMatrix, $hCoverTexture, $hGraphic, $iH, $inifile, $iW, $newfile, $sCLSID $inifile = @ScriptDir & "\Settings.ini" $newfile = @ScriptDir & "\rotated.jpg" If FileExists($newfile) Then FileDelete($newfile) _GDIPlus_Startup() $hCoverTexture = _GDIPlus_BitmapCreateFromFile(@ScriptDir & "\cover.jpg") $iW = _GDIPlus_ImageGetWidth($hCoverTexture) $iH = _GDIPlus_ImageGetHeight($hCoverTexture) $iW = $iW / 2 $iH = $iH / 2 $hBitmap_Scaled = _GDIPlus_ImageResize($hCoverTexture, $iW, $iH, 5) Global $hGUI = GUICreate("", $iW, $iH) $hGraphic = _GDIPlus_GraphicsCreateFromHWND($hGUI) $hBitmap = _GDIPlus_BitmapCreateFromGraphics($iW, $iH, $hGraphic) $hBackbuffer = _GDIPlus_ImageGetGraphicsContext($hBitmap) $hCoverBitmap = _GDIPlus_BitmapCreateFromGraphics($iW, $iH, $hBackbuffer) $hCoverGC = _GDIPlus_ImageGetGraphicsContext($hCoverBitmap) $hCoverMatrix = _GDIPlus_MatrixCreate() Rotate() Sleep(1000) Local $crop = 1, $resize = 1, $trim If $crop = 1 Then Local $lft = IniRead($inifile, "Image Crop", "left", 0) Local $tp = IniRead($inifile, "Image Crop", "top", 0) Local $wd = IniRead($inifile, "Image Crop", "width", $iW) Local $ht = IniRead($inifile, "Image Crop", "height", $iH) Local $size = $lft & "_" & $tp & "_" & $wd & "_" & $ht ; $trim = InputBox("Crop Query", "Please set the desired values." & @LF & @LF & "Left_Top_Width_Height", $size, "", 200, 160, Default, Default) If @error = 0 Then $trim = StringSplit($trim, "_", 1) If $trim[0] = 4 Then $lft = $trim[1] $tp = $trim[2] $wd = $trim[3] $ht = $trim[4] IniWrite($inifile, "Image Crop", "left", $lft) IniWrite($inifile, "Image Crop", "top", $tp) IniWrite($inifile, "Image Crop", "width", $wd) IniWrite($inifile, "Image Crop", "height", $ht) If $wd < 1 Then $wd = $iW EndIf If $ht < 1 Then $ht = $iH EndIf If $lft < 1 Then $lft = 0 EndIf If $tp < 1 Then $tp = 0 EndIf $wd = $wd - $lft $ht = $ht - $tp ; 188_55_630_496 $hClone = _GDIPlus_BitmapCloneArea($hBitmap, $lft, $tp, $wd, $ht, $GDIP_PXF24RGB) Else MsgBox(262192, "Crop Error", "Wrong number of values specified. 4 required.", 0, $DropboxGUI) EndIf EndIf Else $hClone = "none" EndIf If $resize = 1 Then If $hClone = "none" Then $hClone_Scaled = _GDIPlus_ImageResize($hBitmap, 600, 600, 5) Else $hClone_Scaled = _GDIPlus_ImageResize($hClone, 600, 600, 5) EndIf Else $hClone_Scaled = $hBitmap EndIf $sCLSID = _GDIPlus_EncodersGetCLSID("JPG") _GDIPlus_ImageSaveToFileEx($hClone_Scaled, $newfile, $sCLSID) If FileExists($newfile) Then ShellExecute($newfile) GUIDelete($hGUI) _GDIPlus_BitmapDispose($hBitmap_Scaled) _GDIPlus_BitmapDispose($hClone_Scaled) If $hClone <> "none" Then _GDIPlus_ImageDispose($hClone) _GDIPlus_MatrixDispose($hCoverMatrix) _GDIPlus_GraphicsDispose($hGraphic) _GDIPlus_GraphicsDispose($hCoverGC) _GDIPlus_BitmapDispose($hBitmap) _GDIPlus_BitmapDispose($hCoverBitmap) _GDIPlus_BitmapDispose($hCoverTexture) _GDIPlus_ImageDispose($hBackbuffer) _GDIPlus_Shutdown() Exit Func Rotate() _GDIPlus_GraphicsClear($hBackbuffer, 0xFF6495ED) _GDIPlus_MatrixTranslate($hCoverMatrix, 0, 0) ; move it back to 0, 0 since (112 / 2) and (37 / 2) are it's middle origin point _GDIPlus_MatrixRotate($hCoverMatrix, 1) ; rotate it around it's middle origin point (minus to rotate left) _GDIPlus_GraphicsSetTransform($hCoverGC, $hCoverMatrix) _GDIPlus_MatrixTranslate($hCoverMatrix, 0, 0) _GDIPlus_GraphicsClear($hCoverGC, 0xFFFFFFFF) ; show the GC _GDIPlus_GraphicsDrawImageRect($hCoverGC, $hCoverTexture, 0, 0, $iW, $iH) ; place the arrow at the center of it's GC _GDIPlus_GraphicsDrawImage($hBackbuffer, $hCoverBitmap, 0, 0) ; move it's GC by an offset so the image is at the correct XY using it's origin _GDIPlus_GraphicsDrawImageRect($hGraphic, $hBitmap, 0, 0, $iW, $iH) EndFunc Resulting image. Enjoy! P.S. I should have probably removed the comments by UEZ in the Rotate function, especially as I changed it to not rotate around the center. Some of the code in that function is likely redundant too, because of that change.

Thanks for sharing. Sounds great. Yes I have now. Thanks for pointing me toward it. Bookie Bookie ...Yum Yum ... me like books ... tasty tasty ... especially ebooks ... and epubs are my favorite.

Thanks, but I don't recall when I last used this my script, so I probably need a refresher to work out your benefit ... which I am guessing is faster etc. Meanwhile, I did read your topic and grab your script.

Thanks for sharing. Will check it out.

TheDcoder and I along with Xandy, and occasionally a few others, used to chat regularly on the AutoIt channel on freenode, then at his recommendation we moved from freenode to OTFC. But I eventually decided I was wasting too much time on such chats, had too many other better things to do, and it had just devolved to TheDcoder and I, and we mostly argued about all sorts of things, which grew tiresome in the end ... and now he argues with me all the time here ... there is no escape. He is young and contrary ... you have been warned. By the way, it is AutoIt not AutoIT ... as in automate it, not an IT department ... especially not one for Autos. P.S. Actually the channel we use/used was #AutoIt4Life. P.S.S. I was born in 1959, so yes I am old, and my head has nearly fallen off, due to all the negatory shaking that TheDcoder causes me to do ... not to mention the eye-rolling.

Interesting sounding project. Hope it goes well. @Xandy would likely be very interested in this.

While that can certainly be an important factor, even if you could, it still wouldn't make any difference as a threat for all the reasons I stated earlier.

Thanks and all very interesting, but I stand by my last post. Many are just leveraging AutoIt in some way, and though I did not dig deep into any of them, they hardly seem a threat. For Python to be a threat to AutoIt, it would have to be rewritten to feel like you are using AutoIt ... same structure, same naming conventions, same method of use, same kind of Help file examples, etc. P.S. I don't think many folk are going to say - Let's use Python instead, because on the tin it says it does all that AutoIt can do and more. Folk tend to use AutoIt for its simplicity, and Python is nowhere in that same ballpark.

If that is the case, then yes I guess it makes Python more powerful. It doesn't really impact AutoIt users though, unless they are a Python user who only uses AutoIt to make up for the previous limitations of Python. Generally folk who come to AutoIt and then stay, are not looking to go to Python instead. It is all about how you use AutoIt, which is very different to how you use Python, even if they have the same feature set. So in a nutshell, it is all about understanding and comfort and relating to how things are named and structured. Python is very different to AutoIt in that regard. So for me personally, I rarely dabble in Python, only at need, because I simply don't like it, despite how powerful and how cross-platform it is.

But is PyAutoGui really using the name AutoIt? 'Auto' is a very common term, and it is the additional 'It' that is really important. And I say again - so very few, relatively speaking, are interested in cross-platform .... not many more folk than five years ago, and in five years or even ten years, probably not a great many more folk either. The majority of computer users don't care about cross-platform. Something significant in the computing world would have to change, for there to be a change of interest in cross-platform in any kind of major way. And most folk who are truly into programming, don't use AutoIt ... or it is just another tool in their coding toolbox. AutoIt is more under threat by the future of computer use ... especially with the advances in AI.

I cannot really see that as a threat, though I know nothing about a library called PyAutoGui. I do imagine though, that if it is in the Python language, then that alone will be a deterrent to anyone who prefers the simplicity of AutoIt and its no nonsense language that is more eminently suitable for the average non programming Joe or Julie, that wants to get started with coding as simply as possible. And AutoIt can already be leveraged by other programming languages using its DLL etc. Cross-Platform is a big deal to some, but not the huge majority. It would take something significant for that to change in the next ten years.