Thanks Pantxo! I was just wondering whether a more "generic" user-level access to the text_renderer class could be useful in other functions (FontWeight, Interpreter, ...).

I attach where I am so far with insertText.m. I use padarray() so it would indeed probably fit in the image processing package.
Looking back, I should perhaps have used inputParser, struct instead of containers.Map and there might be some functions from the image processing package that could be reused to shorten the code here but I am not too familiar with them.
I added a subfunction str2rgb(): perhaps color_values::str2rgb from libinterp/corefcn/graphics.cc could be made accessible from M-code?

(file #50412)

@Avinoam: I've already been working on this and will share a file tomorrow.

@Pantxo: Thank you - that's exactly what I was looking for. Shall we use _text_to_pixels_ as is or should it be part of something else, e.g. will your work on the latex interpreter be merged into this? Also, can bbox be figured out from size(RGBA) or are there situations where they can differ?

If you want to go that route, I attached a file that should get you going.

Basically _text_to_pixels_ returns a  4-by-M-by-N RGBA unint8 array that you can use to patch the image directly. Actually only the alpha map is usefull.

[RGBA, bbox] = __text_to_pixels__ ("Hello", "FreeSerif", 50);
alpha = double (flipud (permute (RGBA(4,:,:), [3 2 1]))) / 255;

anchor_xy = [2, 40];
bbox = [anchor_xy bbox(3:4)];
idx_row =  bbox(2):(bbox(2)+bbox(4)-1);
idx_col =  bbox(1):(bbox(1)+bbox(3)-1);

fname = "/tmp/Capture.png"
im = im2double (imread (fname));
ncolor = 1;
if (numel (size (im)) == 3)
  ncolor = 3;
endif

fontcolor = [1 0 0];
for ii = 1:ncolor
  color = fontcolor(ii);
  im (idx_row, idx_col,ii) = im (idx_row, idx_col,ii) .* (1-alpha) + ...
                             color * ones (bbox(4),bbox(3)) .* alpha;
endfor
imshow (im, "colormap", copper ());

(file #50405)

@Avinoam: If you're happy with the screen resolution you can use "getframe (gca)" and then "imwrite". Make the figure aspect ratio identical to that of your image, fill the figure and then getframe/print:

## Make the axes fill the figure
hax = axes ("position", [0 0 1 1]);

imshow ("default.img");

## Scale the figure to match the image aspect ratio
pos = get (gcf, "position");
pba = get (gca, "plotboxaspectratio");
pos(4) = pos(3)*pba(2)/pba(1);

set (gcf, "position", pos, "paperpositionmode", "auto")

im = getframe (gca);
imwrite (im.cdata, "/tmp/toto_getframe.png")
print -r300 /tmp/toto_print.png

When using "print", strangely, I still get empty pixels on the right and at the bottom.

I guess the function would go into the non-existing computer vision package. As discussed before, it's fine to use the image processing package until there's enough of these to create a package of its own.

Rik wrote on comment #2:

> On the other hand, servers built without any graphic capabilities are usually just for doing computes as quickly as possible.  Interacting with images typically requires a bit of human interaction.  You might mant to insert text, and then display the resulting image to see whether the results are pleasing.  So a machine that one would use to do image processing probably has graphic capabilities built in.

It's not uncommon for those computers to annotate the results with some text. It doesn't need to be pretty, you may just want to write a count, confidence, or threshold value in the corner or the figure, so no need for human interaction.

Still, insertText is about annotating a figure, so it's reasonable to expect that octave will be built if plotting enabled.

It will work on all platforms because plotting is supported on all platforms, but if you have configured Octave not to have any sort of plotting (No Qt, FLTK, gnuplot) then it would fail.

On the other hand, servers built without any graphic capabilities are usually just for doing computes as quickly as possible.  Interacting with images typically requires a bit of human interaction.  You might mant to insert text, and then display the resulting image to see whether the results are pleasing.  So a machine that one would use to do image processing probably has graphic capabilities built in.

It doesn't strike me as a problem to require users who want to use this particular function to have a fully functional version of Octave.

Changing the category to Octave Forge Package since any implementation would take place in a package, rather than in octave-core.

The function can easily be simulated by creating a figure, puting the image in it, putting the text in it, and then pulling the pixels back out with print.  A rough draft is shown below.

function RGB = insertText (img, pos, txt)
  hf = figure ("visible", "off");  # Invisible figure for combining images
  imshow (I);                      # Add image
  text (pos(:,1), pos(:,2), txt);  # Add text
  RGB = print (hf, "-RGBImage");   # Extract new image
  close (hf);                      # cleanup temporary figure
endfunction

This works for me with a simple invocation like

hf = figure;
sombrero
img1 = print ("-RGBImage");
clf;
imshow (img1);
img2 = insertText (img1, [200, 200], "Hello World");
hf2 = figure;
imshow (img2)