Visitar URL original
Stop using the PNG format for HEIC thumbnails · Issue #41284 · owncloud/core · GitHub
Skip to content

Stop using the PNG format for HEIC thumbnails #41284

Open

Description

@tmysik

Steps to reproduce

  1. enable preview for HEIC files (use the latest Imagick, install php-imagick and enable preview in the config, enabled by default)
  2. upload a HEIC file (photo)
  3. access this file via your web browser
  4. its preview(s) is (are) generated, in the PNG (!) format

Expected behaviour

The preview image(s) should not be created in the PNG format, since this format is not usable for photos at all. In my case, the preview files occupy even more space than the original, large photos themselves (20 GB vs. 19 GB). It seems to me that the e.g. the JPG format would be much more suitable.

Actual behaviour

Thumbnails of any HEIC file/photo are generated in the PNG format.

Note: The reason is that the HEIC.php file that generates these thumbnails extends the Bitmap class which uses only the PNG format and cannot be configured to any other file type easily.

Thank you.

Activity

  1. iasdeoupxe commented on Nov 30, 2024

    @iasdeoupxe
    Contributor

    Could be wrong but looks like all image types (not only HEIC) are getting thumbnails in the .png format, at least noticed .jpg files on my installation.

  2. github-actions commented on May 30, 2025

    @github-actions

    This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

  3. tmysik commented on May 30, 2025

    @tmysik
    Author

    Still valid, no change here.

    @DeepDiver1975 IMHO, this can hardly be an enhancement - try to have 1 GB of HEIC images and let OwnCloud generate 1.5 or 2 GB thumbnails. That does not make any sense at all.

  4. cortho commented on Jul 25, 2025

    @cortho

    I strongly second @tmysik when thumbnails go into 5 Megabytes or more this is clearly no enhancement but a bug.

  5. DeepDiver1975 commented on Jul 25, 2025

    @DeepDiver1975
    Contributor

    Contributions welcome! THX

  6. github-actions commented on Jan 22, 2026

    @github-actions

    This issue has been automatically marked as stale because it has not had recent activity. It will be closed in 10 days if no further activity occurs. Thank you for your contributions.

  7. tmysik commented on Jan 22, 2026

    @tmysik
    Author

    @DeepDiver1975 just curious - why did you mark this ticket as enhancement?

  8. DeepDiver1975 commented on Jun 24, 2026

    @DeepDiver1975
    Contributor

    🤖 Automated issue triage by Claude Code review agent.

    Confirmed and root-caused on current master.

    Root cause. HEIC previews are produced by lib/private/Preview/Heic.php, which extends OC\Preview\Bitmap. Bitmap::getResizedPreview() hardcodes the output format:

    // lib/private/Preview/Bitmap.php:104
    $bp->setImageFormat('png');

    There is no configuration hook to choose a different container, so every Bitmap-derived provider (HEIC, and the other formats routed through Bitmap) always emits PNG. For photographic content this is exactly the wrong choice: PNG is lossless and the resulting previews can be larger than the lossy source — matching the reports here of thumbnail directories rivaling or exceeding the size of the original HEIC library (≈20 GB of previews for ≈19 GB of photos, multi-MB single thumbnails). The size blow-up is a real defect of the preview subsystem, not merely a stylistic format preference.

    Suggested direction for a fix. Emit a lossy format for photographic previews — e.g. setImageFormat('jpeg') with a sane setImageCompressionQuality() (commonly ~80–85), ideally configurable, while keeping PNG where transparency matters. Note the comment from @iasdeoupxe that non-HEIC images (e.g. JPEG sources) also appear to receive PNG previews, consistent with the shared Bitmap code path above.

    This triage does not change the issue's labelling and posts no code change. As @DeepDiver1975 noted, contributions are welcome; the affected line is lib/private/Preview/Bitmap.php:104.

  9. dj4oC commented on Jul 8, 2026

    @dj4oC
    Contributor

    Implementation prompt

    Problem: OC\Preview\Bitmap::getResizedPreview() hardcodes $bp->setImageFormat('png') for every Bitmap-derived preview provider (HEIC and others), so photographic previews are always lossless PNG and can end up larger than the original lossy source image (reported: ~20GB of previews for ~19GB of HEIC photos).

    Acceptance criteria:

    • Previews generated through OC\Preview\Bitmap for photographic bitmap sources use a lossy output format (e.g. JPEG) with a configurable compression quality, measurably reducing preview size versus current PNG output on representative HEIC/JPEG fixtures.
    • Sources needing alpha transparency are not visibly broken (either kept as PNG when transparency is detected, or the trade-off is explicitly documented).
    • Output format/quality is configurable via system config, consistent with other preview_* config keys, with a sane default.
    • No regression to preview consumers (thumbnail rendering, etag-driven cache invalidation).

    Files:

    • lib/private/Preview/Bitmap.php — getResizedPreview() ($bp->setImageFormat('png')) and resize(); add a format/quality decision (setImageFormat('jpeg') + setImageCompressionQuality()), gated by new config.

    Constraints:

    • Test coverage ≥ 85% on touched code (e2e preferred — run the tool, do not trust claimed %)
    • Commit signing: GPG signature + DCO Signed-off-by
    • Rebase onto base branch before push
    • No root-directory edits

    🤖 Automated by Claude Code


    Generated by Claude Code

Sign up for free to join this conversation on GitHub. Already have an account? Sign in to comment

Metadata

Metadata

Assignees

No one assigned

    Type

    No type

    Projects

    No projects

      Milestone

      No milestone

      Relationships

      None yet

      Development

      No branches or pull requests

      Issue actions