Repository navigation
Require image_processing 2.2.0 and drop the transform rename - #82
Merged
Merged
Conversation
image_processing 2.1.0 chose its saver from the destination's extension, so the transform operations encoded to a suffixed sibling of the extensionless scratch path and renamed it into place. Require image_processing 2.2.0, which saves in the `#convert` format to a destination without an extension, and write to the scratch path directly. On the ImageMagick toolchain, a format ImageMagick has no name for, such as `jfif`, now fails as `unreadable` instead of being written in the source's format. ref: janko/image_processing#150 [Fix #4]
The CHANGELOG entry described a known edge case that a separate fix will handle, and did not mention the rename every transform now saves.
This was referenced Sep 30, 2026
flavorjones
added a commit
that referenced
this pull request
Oct 7, 2026
* Fix JPEG variants uploaded as .jfif, .jif or .jfi Since #82, the ImageMagick transformer failed a JPEG uploaded as .jfif, .jif or .jfi permanently as `unreadable`. The Vips transformer has always failed .jif and .jfi the same way. Send the cell the canonical extension of a web image format's content type, which is the extension Rails falls back to when an upload's extension does not match. [Fix #84] * Test that a non-web-image format crosses unchanged The pass-through for a format outside `web_image_content_types` had no test, so removing the guard would have left the suite green. * Note the canonical format in the Vips transformer comment The comment said the format reached ImageProcessing exactly as Rails handed it over, which stopped being true when the client began sending a web image's canonical extension.
This file contains hidden or bidirectional Unicode text that may be interpreted or compiled differently than what appears below. To review, open the file in an editor that reveals hidden Unicode characters.
Learn more about bidirectional Unicode characters
Sign up for free
to join this conversation on GitHub.
Already have an account?
Sign in to comment
Add this suggestion to a batch that can be applied as a single commit.This suggestion is invalid because no changes were made to the code.Suggestions cannot be applied while the pull request is closed.Suggestions cannot be applied while viewing a subset of changes.Only one suggestion per line can be applied in a batch.Add this suggestion to a batch that can be applied as a single commit.Applying suggestions on deleted lines is not supported.You must change the existing code in this line in order to create a valid suggestion.Outdated suggestions cannot be applied.This suggestion has been applied or marked resolved.Suggestions cannot be applied from pending reviews.Suggestions cannot be applied on multi-line comments.Suggestions cannot be applied while the pull request is queued to merge.Suggestion cannot be applied right now. Please check back later.
Motivation
A transform operation writes its output to a scratch path that has no extension. image_processing 2.1.0 chose its saver from the destination's extension. So
Transforming#performencoded to a sibling path named with the format as its extension, and renamed that file into place (transforming.rb#L17-L25).image_processing 2.2.0 saves in the
#convertformat when the destination has no extension (janko/image_processing#150), so the rename is no longer needed.Fixes #4
Details
activestorage-hotcell-serverrequires image_processing 2.2.0, andGemfile.lockpins that version.Transforming#performwrites straight to the output's scratch path.transformers.image.magicknow fails asunreadablefor a format ImageMagick has no name for, such asjfif. Before, ImageMagick ignored an extension it did not recognise and wrote the source's format. Stock Rails is unaffected, because it calls image_processing without a destination. This PR does not address that failure.