drawsave to binary - mIRC Discussion Forums

It would be nice if there were a switch to instead of writing a file, to fill a &binvar with what the contents of the file would be. This is VERY handy when constructing image Blobs to be transmitted via $urlget() or sockets, or any other similar situation and also avoid a HDD write/remove.

Take this example code here, run it and post the contents of your clipboard into your browsers URL Bar:

Code

alias test {
  window -hpf @Test -1 -1 32 32
  drawpic -g0 @Test 0 0 $qt($mircexe)
  drawsave @Test tmp.png
  close -@ @Test
  bread tmp.png 0 $file(tmp.png).size &bimgfile
  .remove tmp.png
  noop $encode(&bimgfile,bm)
  clipboard data:image/png;base64, $+ $bvar(&bimgfile,1-).text
  echo -s Data URL Blob copied to clipboard!
}

And you should see a proper loaded image Blob of the mIRC icon!

It's not documented in the help file of what all types mIRC can /drawsave as, but there's enough info to deduce bmp and jpg based on the flags. Tests show saving to PNG also work.

With the proposed flag of -BN where N would represent image type (0 = bmp, 1 = jpg, 2 = png, etc...) We'd get a result like this without having to save/delete a file (this one's pseudo-code and won't work!):

Code

alias test {
  window -hpf @Test -1 -1 32 32
  drawpic -g0 @Test 0 0 $qt($mircexe)
  drawsave -B2 @Test &bimgfile
  close -@ @Test
  noop $encode(&bimgfile,bm)
  clipboard data:image/png;base64, $+ $bvar(&bimgfile,1-).text
  echo -s Data URL Blob copied to clipboard!
}

A typical Blob consists of a string format, data: <mime-type>;<encoding>,<rawdata> and can be more than just images. For more information check out MDN

https://developer.mozilla.org/en-US/docs/Web/API/Blob

If the intent of this alias is to make a square icon, I'm not getting that. Instead, this gives me a rectangle window and imagefile with a lot of white space to the side. And when I check the dimensions there's nothing that matches the 32 with specified:

//echo -a $window(@pic).dw $window(@pic).dh $window(@pic).w $window(@pic).h

result: 101 32 109 60

Ah nice catch, this is due to mIRC adjusting window sizes to make them fit in the MDI area when a window is created. To get around this, you need to use /window twice....

Updated:

Code

alias test {
  window -hpf @Test -1 -1 32 32
  echo -s * Debug: first window call- DW: $window(@Test).dw DH: $window(@Test).dh
  window -hpf @Test -1 -1 32 32
  echo -s * Debug: second window call- DW: $window(@Test).dw DH: $window(@Test).dh
  drawpic -g0 @Test 0 0 $qt($mircexe)
  drawsave @Test tmp.png
  close -@ @Test
  bread tmp.png 0 $file(tmp.png).size &bimgfile
  .remove tmp.png
  noop $encode(&bimgfile,bm)
  clipboard data:image/png;base64, $+ $bvar(&bimgfile,1-).text
  echo -s Data URL copied to clipboard!
}

Output:
* Debug: first window call- DW: 120 DH: 32
* Debug: second window call- DW: 32 DH: 32
Data URL copied to clipboard!

You should be able to paste your clipboard into your browsers url bar, hit enter, and now see the icon as 32x32

Strange about the window -f, as the 2nd call only seems to work if the @window is -hidden or -minimized. As soon as the window becomes visible, it widens - possibly to make more of the titlebar visible, and it won't shrink the @window unless you minimize or hide it again.

I would like to see this feature implemented as well.

Thanks for adding /drawsave -v in the lastest beta.

A subsequent suggestion is now to be able to draw back the binvar into the screen.

I wanted this original suggestion to avoid storing on the disk like Talon, but I'd also need to be able to draw it back later, this is for a replay thing.

Could /drawpic be extended to draw from a binvar?

Follow up on this, a 1162x706 bitmap, when saving to disk, take a maximum of 2.34mb with bmp extention.
When saving to a binvar, the binvar contains 3.12mb (switch -q and -b are ignored when saving to a binvar).

I'm not sure why this is, if it's normal or not, but at this rate I can only save 15s worth of frames in memory before it errors out of memory.

What's the format saved to the binvar?

Well, Talon's original suggestion was implicitely wanting a png format, so I believe the current drawsave -v won't work for him.

I'm not sure how one can use the binvar atm if not to /bwrite it, which drawsave already offers.

I believe that we need to be able to indicate the format for binvar as well, I'm not even sure the current format is something people want. I think saving to a binvar should offer the same format as saving to a file.

One issue is that the png format was based on the file extention and with binvar, there's no way to find out. A new /drawsave -p switch could be added, to specify the png format (could then allow a filename without extention when saving to disk as well) in this case.

Quote

Follow up on this, a 1162x706 bitmap, when saving to disk, take a maximum of 2.34mb with bmp extention.
When saving to a binvar, the binvar contains 3.12mb (switch -q and -b are ignored when saving to a binvar).

Thanks for the feedback. I have not been able to reproduce this here so far.

Quote

Well, Talon's original suggestion was implicitely wanting a png format, so I believe the current drawsave -v won't work for him.

Ah, right. I didn't see that.

It looks like this is going to take a lot more work to make it usable. I have reverted this change for now and have added it to my to-do list.

Aw

I thought it would be similar to save to a file and to save to a binvar in this case.

Quote

I have not been able to reproduce this here so far.

The numbers may change but you should observe a larger size when saving to a binvar than when saving to a file with maximum file size (bmp 24 bits), otherwise I'm not sure exactly what is it that you couldn't reproduce.

Glad to see /drawsave -v made it to the next beta with the ability to save different formats.

Is there any plan to add support for drawing back the binvar to a picture window in this beta cycle?

Thanks for drawpic -v, all my tests seemed to work correctly.

With .png format it takes 38.8kb to save a frame of 770*678 pixels, if you take 24-25 frames per second, it means saving a frame every ~40ms and after 12minutes or running, mirc only takes 543mb in memory.