Image Lister / Browser stack

[OpenXTalkPaul]

I wanted to see every image ID that gets used by or is reserved by the IDE, so I made this tool stack that can generate a list of IDs in a given range, resolves the chunk/path to the image, and displays a 128x128px preview of the image that's selected from the list. Not as straight forward as one might think. You can also scan for images of a non-srciptOnly mainstacks from the pop-up menu. You can use the arrow-keys to scroll through the list of images, which is interesting because some are ordered frames of an animated sequences.
Plenty of room to make it more robust, do more like scan any substacks of stacks.

ImageBrowser.oxtstack

(268.6 KiB) Downloaded 283 times

[richmond62]

a list of IDs in a given range

Isn't there a risk, because you confine yourself to a given range, that you'll miss some images?

[OpenXTalkPaul]

a list of IDs in a given range

Isn't there a risk, because you confine yourself to a given range, that you'll miss some images?

I was, at least initially, only interested in certain ranges of Image IDs because they're reserved by the IDE and I'm interested in possibly making changes to some or maybe adding a few into any empty slots (like 'smooth' versions of the 'brushes' images) but in order to do that I first need to know if there are any empty 'ID' slots in a particular range.

I added the 'scan selected stack' for images popup menu as an after-thought. That listing method certainly could be more robust. It currently does NOT look into substacks, so that listing certainly will miss any images that are in any substacks of a stack.

[richmond62]

One of the limitations of the FIND stack is that it cannot perform an object search:
-

Screenshot 2024-07-09 at 11.17.13.png (101.79 KiB) Viewed 16628 times

[richmond62]

To access details of resources in substacks you will have to open them all so you can search in them.

[richmond62]

Screenshot 2024-07-09 at 16.41.41.jpg (214.04 KiB) Viewed 16620 times

-

[OpenXTalkPaul]

I made a few changes to the original stack, including looking inside substacks of stacks in the stack image lister method.
I kept getting what appeared to be image corruption, but only with certain index color GIF lz compressed images or certain SVG data compiled and placed into an image control. But then manually placing the very same images they looked fine. So I thought that maybe it's my method of copying the data of an image to into a new image and resizing to 128x128px preview. Then I found the syntax 'prepare image tMyImage' which was introduced in 6.0 engine. Using that syntax loads the image into memory first which decompresses and subsequently renders these images properly.

[OpenXTalkPaul]

ImageBrowser.oxtstack

(250.72 KiB) Downloaded 34 times

Updated this tool so that it can convert/ copy a selected image as a DataURI, which can be pasted directly into the address bar of most web browsers in order to view the image, DataURI can be used in modern HTML in place of a URL as a way to embed data into the HTML itself.

It's a bit more tricky than I'd imagined it should be to get image data from image controls for several reasons:
1) the data can be formats such as RLE encoded bitmap or netPBM that aren't natively supported on the web.
2) the image data may come from an URL or external file, which may be a relative path that could be relative to the stack file the image control is in and that needs to be considered when resolving the path to the image file into a full path.
3) The image may actually only contain an ID number of an Image in a stack or image library in memory. which needs to be resolved.
4) the image data may be in revDrawingLibrary's proprietary 'compiled SVG' binary format which as far as I know cannot be converted back into normal SVG data, so those must be exported to snapshot as PNG (best for retaining transparency in images).

I had 'rolled my own' previously for checking image formats by reading the first few bytes and checking for 'magic-numbers' such as 'GIF87a', but that doesn't help with RLE or 'SVG-compiled' image data.
'The paintCompression' keyword was very useful this time for checking the file-format of image data.
Here's a breakdown of values:
1) If the image data is 'compiled SVG' format then getting the image's paintCompression value returns 'pict' (which kind of makes sense since 'PICT' from classic MacOS supported 'MacDraw' vector art)
2) If the images paintCompression is 'rle' compressed format then it's probably an ancient MetaCard Icon, but the point is it would need to be converted to a compatible graphics format for use on the web.
3) the rest are what you might expect 'gif','png','jpeg', all web friendly formats so no conversion is needed.

[OpenXTalkPaul]

It's weird, I have a few test 'images' with SVG compiled data in them that do not want to display in a browser after the conversion for some reason.
Like this one doesn't show up in Safari for me:

Code: Select all

data:image/png;base64,iVBORw0KGgoAAAANSUhEUgAAAFMAAABNCAYAAADabljrAAAABGdBTUEAALGPC/xhBQAADB5JREFUeJztnO1vHFcVxn/j9dpex83Sxq3rpHVK0pYgSGldUFWoEFERIJXyoa1QBRTlA4jXP4dX8a0ChBDiA+9U0PCSEEWNXJWAFGgMqZOQpnVSNom9SfwyfHjO4Y7XO7MzO2s7TvNIo53dnbn33Oeee86Zc+8duImbuIkbHNFGC5CFOI5HW3+Lomh2I2TJgw0nM47jcWAUqNtPqwjMgBPbAGajKDrbS9mKYt3JjOO4jghzElsxAFSBCjDU5v8rwBKwAFxr8/9ZRPJsFEWNXsicF+tCZhzHVWA3MAEMJ/4aAmrAlsR5UTQRwXOJc8c8MANMR1G00EXZhbCmZCZI3I20DUTYrWhYD7TccjFx3mj5fWviez1xnvwdpK0N4C1ELkiLp1ljUteEzBQSb0NDO0ngHCLqPCuJLIqtwDb73JL4/Roa9hfs+5qS2nMy4zjeDewh2L077Oi3S94kaM5ir+sHBhGpdeB2+20ReMMOt7fHoiia6WXFPSPTtHEvsosgTdmBGgci8TRwtVd15sAgcBeB1KvAGTQSQPb0WK+0tCdkmoeeRNowCNxHcDSzlCdxsAf330WIHi4B/7IyG8BULzx/aTItTpxEw/pOJHQ/8qSvUp4E75hel7eIOvl1NOynysappciM43gvcjIV4J3INmIClrVHw8j29qNwZwgRcBwRWwYTqONBdvSEnU9HUXSs20K7JjOO40kTqoJs5Qgy7v9GzqUMbkWdUwHOIY28DxhbozouA8es7Jkoiqa6KbArMls08n2IyHngJOW1ZhtqJMBrdjh22gEi9DzlMAzcY5+XgVcQocejKDpetLDCZMZxPIFsZD+ByPPAKROkDO5BZIKG8zlkz44Twq0xOwcN0VMl66xYve8gELqIbGghU1WIzBYiH0JENoF/Uo7ICnJc21BDXkYNWwAORlHUsIjhMUToiNXfjzrydA/qvx89nV22+gsTmpvMlsZMIpvjHrZsQ9zDNoG/ogY1EJH/jwEtln0MhWAjwAOIgF7L8RYwRaIz8xSQi0xrxMcQke9CjmcJ+DvlGlBDNrCGYr+jSCNmgSPtgmmT5REUM/YD7wduQR3xGuF5vBsMIBNSQdHIPxChL+QJ7POS6Z77DuBBROAJygleA+5Fgr8B/A0RmcubJmTqB95rsvVarpeQluaSqSOZNrz3IaE/ZJVNo6HYLW4D7rbzMygsAT3aTectJI7jPQRntBc9vi4B/yEkN7pBHTmlJnAIdfKBTsO9L0fBe+3zfpSRadpR6fIYQ0O7D2mjEzlVhEgAC19cY44hr1+18sdKyHjZ2rjF2p3kIRWZZJr3HkVGeZddf8Y+uzl2Iq+9hBzNaWSTDnSbwbH7Dlg5J63cJavHO62bw9u5y9o/anykIpVMM/Q+hN5j175pghbt6QETapvdfxgROU8Bb5kGu/+glXfayl+y+nZZ/UVlXkKmog85XYA9xktbZGmmTzHUge3AMjLGRXvYE8V1lAD+i302yGGH8sLKOWDlJuupE5LURWWftXZPWDnDhBTjKmSR6emqe+26N+x7kd7dgrR7GIU+h6yxM7TEkL2AlXcQZdcbVt8lq99tfhH5sXb3GQ+QMXvalkxT5XHUm9vtujmK9eotaIhV0SPfi8iuzURRNLVWczFRFC1EUXQEddgC8Gerf9DkuaVgO7zd260t42lDPU0zx+1zB0p9zdn3vD3qtqqK4r6jdv9UtxmZorB6/CnmqMlRJdjuIto5h3jYYd+dnxXoROZdhN4pEvr4fS+hxIEnX3s659IJVp8T+orJ02fyFQmdriTugxQy+1t/SAxxEjfPky8mHUeGegE4Qgh9SnvsbhFF0Uwcxw30TH8SBeCPoCemQWRfO2EOPeCM2ffxOI6rraZqFZkEAzuGCPRpgkqbax19aAgMI/JeRJ6/gZ6xy+Y4S8GyTgdRggZEzkdRsmYQxZTLGUUso3YNIl7OIZ5WdEQ7Mn2Cfwz1hhvgNLiTGkQE/o6wbGUWmIjjOOP2dcUsat9bwK+BDyNCd6JH0Cyn6HbTyayTg0zHCEEbs7RyJyL0deAPrFz/szvjvo3GZdTxHyFMBHay6RXES1tkaeZWpJkLpGtmFT1dXEO99e4OwlyPOIe8e82OtNnPBcSHL8ept17QjkyPodwJJUOEViwTEgKTKddsFswh55TW1gpSKudlVayZRaZrY1YFoCeE/naFbyIsI43MauciK0doLjJdfZO5zk5hkQuzmZEn9EtykmuYtxae1VtvN2QSnofMPD32dkFhMhtIhf3GKtkBLcijb2bSF+m8vNETH45VT3TtyPTA1e3DECuXNrfidlYurd6smEfJ7zQMsdJmrgrws8g8ix4Rs0KjAUIQeyZL0uscO1A7LpKuoR4aeTtzkdlAsdQlu3mo3Y2GJTuqqNd+weby6oPAJ1E7l4CYdMUZsusu2fdcw9zhZHqPpOECeoKYAJ4BfkIgdJrs5931hk+hgJ5knkTZo2toiGe103m4lHZBmmZCmJ0bISSH2yEmEHon8AXgxybcKNdB1ghWrG4G2flPI227iuSPyA4DR1g5zFdpZrue8F1fp1CP+SanrNQ+aAFVEz3fPovmTOrAPmvIhiGxTqpucj2L5GwSliV2mhT0HMQpu37VtsNVZFrC01NLp+2aYfJlpC8iLa4BT6GJ+yrwWKc557WC1esLzvaaXDXCtpm8E4N9iA+As+3msNJshJN5gmJkVlCIcdHuewJ43Boyud6EJpZAVk2OJ0yuiyZn3jbV7D5frt02O5/mgPziV5Fq+1Rtp+DdcRUlYG9FUwQ15Okn4zgeXY9JtcTCriGUVX8AyX+B7LRiK1yZriA+oAiZURQtxHF8FoVIJ0wQXz+ZF0vAfxGhDyLn9H1C5r1n+2+SsDmsSST7EPA5q9vlWaZYviGplVdIGeKQ3TtuYI8gT1cnhAd5D9eEJWvccyjtP4HsaE/TdonFsONWz3N27ktdlgvKX7F2R8CfrJrUCbgsMmeQXTmHlllX0AR+kRURTn4DDa3twH6kKT319Imlj3Urf7/Vt2D1OzlFjq32eQxp9TzdkGmq7DsOXiCs0uhmzU6EbO5VZC72o6E/jDS0FKGJ0GfYyt1v51et3qgLmX3tfB/wR6vqeJZpynoC8jln98BHgEdRz3c7Bz6PgvwR4GnUyJeRhna1SCHhsUGbBp6y80vIxnWbj/XM2WHkTGc7yZfHo/li1BcRiUN2FB0yflwjPFE9g0gFefpCs5m2ctiJfNrKw8pfKCFjzdrYsHYneUhFRzJtJcYM6uVfEZyR5zC7ORYIy7gfRh53CNhrIU1H2HV7CB77YfvLt7x0K9sAYWb2p9bumTwrUrrZbfEkWtseo57LG3u2g89DV9AigO+h8Cvvbosa8EXkaJYQkWV2f/QRvPch4Of0ercFrNoH9CWUfVlEtqnMko0IObZ+FL48j4jttA9oO/B5tNmg13JMA99lLfYBORLGvgZ8GSVVF5FGlG1IDeUXm8C3CctV2u1Q2w58hbBooNmD+kcQkWeA71iZa7NDzdFC6FdRw65RvkEQCAX4EVoC2Lp38gMo6wOByDKIUBhVRR34Lbog0gsqjMT+mxrwNcL+myblN6MOEF7J81vgN4n/PgF83M6btH+vURG4564gjfymlbs+u3odiUTCMPB1RGhswpR9kUk/amSE4tsfAp9BjqdXdVQJk2RngG9g70Fa1/3mjsS+c4DPosaChmbWjGYeVAiznheQowE1uKz2DxGWtxwBfmDnG/MmBEfLOzr2oZxhDTX4CuVCJ5/Qq6xBeU3gl4QNWRv7jg5Hy9tjtqGQ5T7729/ZVtbblr3fp19Aecnn0ZTF9fP2GEeb9xo9iqZR/c0Gi5QntSicRM9BnEdJ6sP2fYbr7b1GSVjo5HM/w2i64HGCh15EQ9XnqXsNn2XsI5DYBH5vxzzX+xu3kkh5F9wHgU8RNBVEpi9kKGsLPUmRbNN54Gdo6x9stnfBJZFC6gR6tn+IlcSCyHVtTZLrGXKQzFGbc8d5lNY7RFijvnnfUtiKjPdnjqLgfw/azN/N7OUMmss+bkdyPvvGeX9mOyTe7Opvd23F7YQ97ne3+f8UImmW9qvWbuw3u2ahzTuH6+RbH+9zO/B2fedwEWy2t2HfxE3cxA2P/wH+pe0BBMfa3wAAAABJRU5ErkJggg==

Ooooh now I see, its probably the /slashes/ in the base64encoded data, a no-no for URLs. Normally you wouldn't paste these DataURIs into a web browsers address bar (although it does seem to work for most images.

But maybe not, it shows up in Chrome on darkmode so I'm thinking it has to do with this particular image being light and then on white background and also having transparency to it.

imageData.png (3.1 KiB) Viewed 1701 times

[OpenXTalkPaul]

Added a button to wrap the dataURI in a HTML container easier for testing and probably for future use as part of a larger export mechanism.

ImageBrowser.oxtstack

(533.37 KiB) Downloaded 21 times

Screen Shot 2025-04-23 at 2.03.53 PM.png (1.1 MiB) Viewed 1588 times