https://github.com/lucee/Lucee/commit/8709817fbefd6006e0000616332b0833e784f143

For an example of backwards-compat issue check the first answer on this SO post. This how we used to convert to binary:

<cfset img = imageNew("",200,200,"rgb","red") />
<cfcontent variable="#toBinary(toBase64(img))#" type="image/png" reset="true" />

https://stackoverflow.com/questions/5636874/how-do-you-write-a-image-to-browser-as-a-binary-stream-in-coldfusion

I don't know exactly why toBinary(img) wasn't the way we did things, maybe it's an old Coldfusion bug/limitation but the workaround was toBinary(toBase64(img)) which no longer works as expected.

Also worth noting is that toBinary() with image arguments is undocumented in Lucee and Coldfusion. Both claim to only support PDF and Base64 args. Also there seems to be a suggestion the function is deprecated in favour of BinaryDecode

https://helpx.adobe.com/coldfusion/cfml-reference/coldfusion-functions/functions-t-z/tobinary.html
http://docs.lucee.org/reference/functions/tobinary.html

Thanks for raising this issue but I feel the description doesn't clearly explain the concern I was raising in my post. It may not even be a bug depending on your definition/opinion of what the behaviour should be when "stringifying" an image object (ie, created by ImageRead()/ImageNew()). The issue is explained here:

https://dev.lucee.org/t/unexpected-tostring-behaviour-on-image-objects-in-lucee-5/2704

The underlying question is whether toString(myImageObject) should output a "binary string" (lucee 4 behaviour) or a HTML data:image tag (lucee 5 behaviour). The lucee 5 behaviour simplifies outputting images to the browser since you can presumably view an image by simply adding #myImageObject# to a HTML page. On the other hand it breaks the expected behaviour of toBinary(toBase64(imageObject)) which used to be the way to get a binary version of the raw image data because for reasons unknown toBinary(imageObject) wasn't supported/working.

Since posting that question though I've discovered through trial-and-error that toBinary(imageObject) now gives you a true binary representation of the image which means the only use-case not supported is toBase64(imageObject) because it isn't giving you the Base64 of the image DATA, it's giving you the Base64 of an image TAG, which is useless. This can worked-around though by writing toBase64(toBinary(imageObject))

So the end result is that the solution here is opinion-based because it could be one of:
a.) Make sure toBase64() operates on the binary representation of its argument and not the string representation.
b.) Revert so the string representation of image objects isn't embellished as a HTML data:image tag but just raw characters in the octal range 0-255 (lucee 4 behaviour).
c.) Do nothing except update documentation, code, examples to reflect that toBinary(imageObject) is required before encoding an image as Base64 or doing anything else with the image data other than directly rendering it to a HTML stream/string.

I've added test case for this ticket

Pull request: https://github.com/lucee/Lucee/pull/281