Re: [Texmacs-dev] eps image is pixelated

[Michael Lachmann]

I don't know if you remember, but I once had a patch that stored converted (eps->png)

images in a cache directory, based on the CRC of the file. It worked quite well,

and as a bonus also took the hardcoded gs command out of the source code.

When you open a file with lots of EPSes, it really helps.

Joris asked me to convert it to C++, and it stopped there.

Anyway, I don't know if this is needed if the images are stored in cache. But the cache is not saved

for the next time TeXmacs runs, right? So maybe it is beneficial.

Should I restore that? (And if I add the CRC caching to the C++ source, where's the best place to put it?)

Michael

On 13 August 2013 17:23, Miguel de Benito Delgado <address@hidden> wrote:

If I understand correctly, -dTextAlphaBits and -dGraphicsAlphaBits control oversampling. Would this noticeably affect performance / memory usage? Unlikely...

Also, I just noticed that scalable_image doesn't use the cache, which means that the system command executes (a lot of times!) every time the canvas scrolls, a new paragraph is inserted, etc. Just telling scalable_image::draw to use the image cache fixes this and of course greatly improves performance.

If the user repeatedly changes the size this will imply a lot of memory used, but since the cache is periodically cleaned, I think we could live with it (ideally we would delete the previous instance of the same image upon rescaling).

Best,

--
Miguel de  Benito.

On Mon, Aug 12, 2013 at 5:27 PM, Michael Lachmann <address@hidden> wrote:

I see. The problem difference stems from this function in src/Plugins/Ghostscript/gs_utilities.cpp

--

static bool

use_converts (url image) {

#if defined(__MINGW__) || defined(__MINGW32__)

  (void) image; return false;

#else

  // NOTE: determine whether we should use image magick.

  // Indeed, EPSCrop unfortunately does not correctly handle

  // non trivial offsets of bounding boxes

  static bool has_image_magick= exists_in_path ("convert");

  int bx1, by1, bx2, by2;

  ps_bounding_box (image, bx1, by1, bx2, by2);

  return has_image_magick && (bx1 != 0 || by1 != 0);

#endif

}

--

which says to use image_magick when one of the origins of the bounding box is not 0.

Later, gs_to_png calls either convert or gs depending on the return code.

So, if convert gives better results than gs, why not call that always when available?

Or, why does gs give worse results than convert?

I found a simple solution, though I think that the behaviour above is quite inconsistent.

The call to gs in gs_to_png needs an extra parameter:

--

    string cmd= gs_prefix ();

    cmd << "-dQUIET -dNOPAUSE -dBATCH -dSAFER ";

    cmd << "-sDEVICE=png16m -dGraphicsAlphaBits=4 -dTextAlphaBits=4 -dEPSCrop ";

    cmd << "-g" << as_string (w) << "x" << as_string (h) << " ";

--

You need -dTextAlphaBits=4  to also have text smoothing.

Michael

On 12 August 2013 16:09, Michael Lachmann <address@hidden> wrote:

Hi!

When I display an image from inside and R session, the result looks pixelated.

I don't think this was always like that.

Look at the attached files. The only difference between them is the boundingbox line

%%BoundingBox: 1 1 504 504

in the eps. One starts from 0 0, the other from 1 1.

The 0 0 one (the original one) is inserted pixelated. The 1 1 is inserted smoothly.

(Insert with Insert->Image->Insert Image...)

Why is that?

Can I do something so that eps is always inserted smooth?

Michael

_______________________________________________
Texmacs-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/texmacs-dev

_______________________________________________
Texmacs-dev mailing list
address@hidden
https://lists.gnu.org/mailman/listinfo/texmacs-dev