Okay. This is on a completely different note, as I investigated what I proposed as an alternate solution to generating the images in Excel. I am speaking of what I wrote here. (Although I did it in Microsoft Excel).
Perhaps if the images are put into a folder which is linked to a FREE spreadsheet software (like Open Office) such that the images are loaded into view as the user scrolls down the spreadsheet, this could be another solution.
Here is a < 4 minute video showcasing
this idea. In it, I explain the disadvantages and the scope of how we can use it. So it's your call. What I said before about using a search engine in the sheet can still apply here. It just will pull up images from a file (from a file path of your choice) instead of generating them. But if you are set on pulling up one image at a time, the previous idea would of course work as well.
But what I forgot to mention is that as you arrow down (or up), the previous image is
deleted. So the spreadsheet will only have that one image (or 7-10 images) in it at all times. And of course another disavatange is that you have to generate the images somehow too. If @
Habsen's software can generate the type of images you want, we can combine both of our software's capabilities to give you what you
really want. (You can use my software to create images, but it will be about 8 times slower than @
Habsen's (since he estimated that it takes a few hours to generate 100k images . . . where I take "few" to be 3 hours . . . hence an image every 0.1 seconds instead of mine which is one image every 0.85 seconds.)
Lastly, I don't know how fast scrolling up and down a sheet with this new idea will be (speaking in terms of displaying, say, 7 rows = 7 pictures to be inserted (and 7 images to be deleted) upon each keypress). I
assume it will be fast enough, even though it should be slower than running down a spreadsheet without code parsing upon every row change via a keyboard keypress. (But it will certainly be faster than running down a page with 10 images in it instead of 100k images in it!)
(In short, you can do A LOT with VBA. And this was just a few dozen lines of code total to do!)
EDIT:
Regarding what I said in the video that it would be "hard" to keep the images from the folder to correspond to the row that the algorithm is in, there are ways to do that programmatically -- keeping a table of two columns, where one column contains the images' names (the images in the folder/the source images) and the other column being a primary key of some kind -- perhaps the
Cube Target column which is in the spreadsheet.
But even with that, there's always a risk. But here's an idea of how to make it work (with little to no risk). (This is sort of how telephone numbers, vehicle license plates, etc. are indexed.) Think of the full primary color palette. There are 0 to 255 for Red, Blue, and Green.
- I have VBA code which can pixelize an image into an Excel spreadsheet. (Not my own.) It's very slow though. (Again, I didn't use it to pixelize the cube image that I used. I used the online software that I linked to, as it was instant.)
- However, the cube images can be generated so that just the top-left pixel is a specific RGB color shade.
- So I run the software to pixelize a cube image, but stop it as soon as it draws the first pixel (that is, gets the top-left pixel from the image from the source file). Then we have a hidden column (or maybe three columns) in the spreadsheet which holds the RGB value. So each row has a different (unique) RGB value associated with it that corresponds to its image.
- This way you can literally re-order the images, and or remove cases, and NEVER have to worry about renumbering the cases as images come in. (This is assuming that you keep the image assoicated with a case.) Reason: There are 256^3 = 16,777,216 possible RGB shades. So you can assign a unique shade to each image and can literally afford to redo the entire set of 100k algs 167 times if need be (where I don't think you would have to redo even the full set once . . . it doesn't make sense that you would) and still have a primary key number for "each image to case connection".
- The two-column table index of the primary key can be run to "re-calibrate" the images with the data once in a while, but it certainly doesn't need to be done while viewing the images with the interface I proposed above. (And this is something that only you have to do, not your audience.)
- I don't know exactly how stable the image-to-pixel VBA software code I have is (or how long it will take to get the top-left/first pixel of an image), but if it's reliable, then this could be an approach to doing "the impossible".
