Rotate is JPEG-only: PNG and WebP need a hard rotation to be supported

オープン
  • 何か問題がありますか？
#47 コメント 0 件 リアクション 0 件 担当者 0 名 GitHub で見る

メンテナーはふだん 1 日以内に返信

まだ誰も着手していません。

評価

難易度
4/5
見積もり時間
3〜5日
初心者へのやさしさ
54/100
issue の種類
機能追加
明瞭さ
おおむね明確
活発さ
活発
技術スタック
typescript
領域
frontend

調査の方向性

lib/private/Image.php:413、lib/private/Preview/Image.php:42、lib/composables/useExportImage.ts から始め、特に 112 行目の jpegSource() と 235 行目のダウンスケールされた結果を確認してください。@nextcloud/image-editor の state.rotation、orientedSize()、ENC0DABLE フローを比較してください。完了条件は、エクスポートによってメタデータと寸法が保持される場合にのみ PNG の回転を利用可能にし、ダウンスケールされた出力を拒否し、エクスポート中も PNG メタデータを保持することです。

索引モデルが issue の本文から書いたものです。

説明

AI assisted status: triage type: enhancement

The rotate button being added for JPEG writes the Exif orientation tag: two bytes, no decode, no re-encode, nothing lost however many times it is pressed. PNG and WebP have no equivalent, so the button is hidden for them and those files cannot be rotated from the viewer at all.

Neither format carries an orientation the stack honours. lib/private/Image.php:413 in server returns -1 for anything that is not IMAGETYPE_JPEG, so fixOrientation() in lib/private/Preview/Image.php:42 never fires and previews would keep the old framing even if the file did carry a tag. PNG's eXIf chunk and WebP's EXIF chunk are both dead ends here.

The only route is a hard rotation: decode, turn the pixels, re-encode, upload. @nextcloud/image-editor already does exactly that (state.rotation, orientedSize(), ENCODABLE), so the work is not the rotation itself but deciding whether the result is worth writing.

I measured four 90° turns, decoding and re-encoding each time, on an 800x600 synthetic photo:

format PSNR after 4 turns, Chromium Firefox size after 1 turn
PNG bit exact bit exact 292KB → 273KB
WebP, default quality 40.4 dB 43.0 dB 14.4KB → 14.7KB
WebP, quality 1 bit exact bit exact 14.4KB → 141KB

PNG costs nothing in pixels. toBlob('image/webp', 1) turns out to be lossless in both engines, but a lossy source re-encoded that way grows 10x in Chromium and 3.4x in Firefox.

[!IMPORTANT]
The pixels are the easy part. What blocks PNG today is that the export drops metadata and can silently shrink the image.

jpegSource() (lib/composables/useExportImage.ts:112) returns null unless source and target are both JPEG, so carryMetadata never runs for a PNG: eXIf, ICC and text chunks are gone after a rotate. And the export is subject to the canvas cap, reporting downscaled at useExportImage.ts:235 when it had to work smaller. A rotate that quietly resizes someone's image is worse than no rotate.

So for PNG:

  • carry PNG metadata through the export the way JPEG's is carried
  • refuse the rotation, rather than writing it, when the export comes back downscaled
  • then show the button for PNG

For WebP, a re-encode has to sniff the source first: RIFF VP8L means a lossless source that can be re-encoded losslessly at no cost, VP8 means a lossy one where the choice is generation loss or a 3-10x file. Worth doing only if someone asks for it.

GIF, BMP, ICO, SVG and the preview-backed mimes (HEIC, HEIF, TIFF) are out of scope: the editor cannot write any of them back in their own format.

主要言語
TypeScript
スター
2
フォーク
1
平均マージ
19時間 47分
マージ済み PR（30日）
78

環境構築

はじめの一歩

  1. issue を最後まで読み、次にプロジェクトのコントリビューションガイドを読みます。
  2. 着手することを issue にコメントします — 二人が同じ作業をするのを防げます。
  3. リポジトリをフォークし、ブランチを切って変更します。
  4. issue 番号を参照したプルリクエストを送ります。

nextcloud-libraries/nextcloud-viewer のほかの issue

nextcloud-libraries/nextcloud-viewer の issue をすべて見る

似ている issue

TypeScript の issue をもっと見る

新しい issue をメールで受け取る

初心者向けの GitHub issue を短くまとめたダイジェスト。