[bug #68049] imread() is slow

"Dmitri A. Sergatskov" <[email protected]>
Newsgroups gmane.comp.gnu.octave.bugs
Message-ID <[email protected]>
Please use the bug tracker to post updates to a bug report.  The mailing list is intended as a read-only notification stream.  Info posted to this mailing list address won't appear in the tracker database where it is most useful.

URL:
  <https://savannah.gnu.org/bugs/?68049>

                 Summary: imread() is slow
                   Group: GNU Octave
               Submitter: dasergatskov
               Submitted: Sat 14 Feb 2026 09:37:14 PM UTC
                Category: Octave Function
                Severity: 3 - Normal
                Priority: 5 - Normal
              Item Group: Performance
                  Status: None
             Assigned to: None
         Originator Name:
        Originator Email:
             Open/Closed: Open
         Discussion Lock: Unlocked
                 Release: dev
        Operating System: Any
           Fixed Release: None
         Planned Release: None


    _______________________________________________________

Follow-up Comments:


-------------------------------------------------------
Date: Sat 14 Feb 2026 09:37:14 PM UTC By: Dmitri A. Sergatskov <dasergatskov>
While working on some other image-reletad bugs i noticed that `imread()` (but
in fact `__magic_read__.cc`) is way too slow.
E.g. using attachde (file 3.jpg)

octave:1> tic; [im, map, alpha] = imread ("3.jpg"); toc
Elapsed time is 0.544399 seconds.
## Reading the same file off the disk is fast
octave:2> tic; s=fileread("3.jpg"); toc
Elapsed time is 0.0105002 seconds.

Also processing this file by GM is also fast:

$ gm identify -verbose 3.jpg 
Image: 3.jpg
  Format: JPEG (Joint Photographic Experts Group JFIF format)
  Geometry: 4096x3072
...
    Tainted: False
  User Time: 0.040u
  Elapsed Time: 0m:0.046155s
  Pixels Per Second: 260.0Mi

So I think "imread" should be at least 5x faster.

Looking at __magick_read__.cc sourse I see that it mixes up C-style vs
Fortran-style (Octave) arrays, but that cannot account for all the
slowness...

Dmitri.
-- 







    _______________________________________________________
File Attachments:

Name: 3.jpg                          Size: 2.0MiB
    <https://file.savannah.gnu.org/file/3.jpg?file_id=58241>



    AGPL NOTICE

These attachments are served by Savane. You can download the corresponding
source code of Savane at
https://savannah.gnu.org/source/savane-9953bb12daa795c366b6ab4c67b1c25dc9ff6156.tar.gz

    _______________________________________________________

Reply to this item at:

  <https://savannah.gnu.org/bugs/?68049>

_______________________________________________
Message sent via Savannah
https://savannah.gnu.org/
signature.asc (application/pgp-signature, 228 B)
-----BEGIN PGP SIGNATURE-----

iHUEABYIAB0WIQQk97aszIMMAvLLwm6qLAuaBUf3TgUCaZDrDQAKCRCqLAuaBUf3
To6UAQCaU9ZgWFYtqezGNPWpjeCkrbqGZDZ6aMR2Z+lcwXX64wEAlHC/iyITJx+y
Dy93kB4NX7KJSWkILg+YXi0MHGYj5Aw=
=k0WB
-----END PGP SIGNATURE-----
lmpx.com only provides a reader for public news (NNTP) servers. It is not affiliated with the servers or forums shown here and is not responsible for the content of articles, which is written by their respective authors.