I don’t have any experience with Octave.
Q1 I have image 2.10.0 but
octave:1> padarray([1,2,3;4,5,6],[2,1]);
'perl' is not recognized as an internal or external command,
operable program or batch file.
error: 'padarray' undefined near line 1 column 1
Works for me on 4.2.1 on W7 (at work) once I load the image package.
I have started to run functions in *.m files; e.g., explore Kovesi's functions and use image quality assessment tools that aren’t readily available in G’MIC.
Curiosity: who uses Octave and / or MATLAB and what do you use it for? If you have examples, even better! 
I used Octave for many years, in the 2.x – 3.x days. I still use Matlab when required for work reasons.
These days, however, I use Julia (https://julialang.org). Julia as a language is so much better than Matlab/Octave, and it’s also much faster (some times 1000x faster).
Thanks for the suggestion. Kovesi offer them in Julia as well. (Does Julia run *.m files?)
Went to its website and boom an impossible colour! Can you see it?
LOL yeah, you can tell they’re not focused on web design 
You can’t run *.m files directly; the syntax of both languages is different. In many cases, though, a manual conversion is not difficult, or even straightforward. The main differences are listed here.
I have no trouble reading pngs. tifs with values less than 1 are another story. tiger_am.zip (431 Bytes)
# gmic
gmic tiger_am.tif e[] {I(0)}
# first pixel: 0.32904687523841858,0.30593395233154297,0.2462676614522934
# Octave
imread('tiger_am.tif')
# first pixel: 37704,29258,7454
What is the best way to approach this?
@afre
This is actually a 16-bit integer TIFF file and not a floating point one, and Octave reads it correctly as such (actually Octave uses GraphicsMagick as its image format engine).
If you would like to convert your image data to floating point, you can do so using im2double() or im2single(), depending on the floating point precision you require. Also note that for a 16-bit file this assumes 65535 => 1.0
Might be overlooking something. When I do
magick identify -verbose tiger_am.tif
the output is
Depth: 32/16-bit
Channel depth:
Red: 16-bit
Green: 16-bit
Blue: 16-bit
What does 32/16-bit mean? Clearly Octave interprets it as 16, while gmic 32.
Not sure, but I found another bit of info in the identify output with debug options:
08:45:47 0:01 0.063u 1920 tiff.c/ReadTIFFImage/1764/Coder:
Sample format: IEEE floating point
08:45:47 0:01 0.063u 1920 tiff.c/ReadTIFFImage/1773/Coder:
Bits per sample: 32
So my bad, it really is a floating point TIFF. Anyway, the pre-built GraphicsMagick library used by Octave only supports 16-bit integers, so this is converted to uint16 first, and then you can convert it back to float using the functions above. You loose some precision (i.e. dynamic range) in the process obviously.
More background:
https://sourceforge.net/p/graphicsmagick/feature-requests/36/
There is one more thing I found out. Because the floating point TIFF defines these tags (from exiftool):
SMinSampleValue : 0.225869223475456 0.225869223475456 0.225869223475456
SMaxSampleValue : 0.405208081007004 0.405208081007004 0.405208081007004
Octave/GraphicsMagick actually quantize on 16-bit only this range, (i.e. 0 means 0.2258… and 65535 means 0.4052…). So to get back your original values you need to do something like:
im = im2single(imread('tiger_am.tif'));
smin = 0.225869223475456; # or (1,1,3) vector if different
smax = 0.405208081007004; # ditto
smin + (smax-smin)*im
Thanks for investigating. I missed those tags and calculated smin and smax instead. Guess there is no way to access them within the Octave CLI.
@afre
Try tiff_tag_read
I am getting
tiff_tag_read('tiger_am.tif',[340,341])
# 398, 410
Ah, pretty weird:
offset has the same structure as value and when equal to 1 its matching value on value will be an offset to a position in the file
The values returned are actually offsets from the start of the file to the real numbers, so you’d have to open the file and read them manually after that:
FID = fopen('tiger_am.tif');
fseek(FID, 398);
smin = fread (FID, 3, 'float32', 'ieee-le');
fseek(FID, 410);
smax = fread (FID, 3, 'float32', 'ieee-le');
fclose(FID);
It looks like this is because tiff_tag_read is relatively simple and does not support reading tags that contain arrays of floats like in this case, only single values…
This image file reading business is getting out of hand. 
The offsets depend on the image in question too. Guess one would have to write a function to make things easier.
Yep 
To make things worse, there is software that doesn’t write these two tags in the float TIFF, so GraphicsMagick just fails to interpret them automatically, and there is no way to get them into Octave directly.