-
-
Notifications
You must be signed in to change notification settings - Fork 1.3k
New issue
Have a question about this project? Sign up for a free GitHub account to open an issue and contact its maintainers and the community.
By clicking “Sign up for GitHub”, you agree to our terms of service and privacy statement. We’ll occasionally send you account related emails.
Already on GitHub? Sign in to your account
Use of toFile with filename ending in j2c or j2k, without preceeding dot, assumes JPEG2000 output #3672
Comments
If I you want to use one of these file extensions but not use the JPG2000 format for the output then you'll need to tell sharp what format you do want, e.g. for JPEG output try: - sharp(path_input).toFile(path_output)
+ sharp(path_input).jpeg().toFile(path_output) |
@lovell What I'm saying is that when an error is reported, the error is cached |
Please provide complete, standalone code that allows someone else to reproduce. |
sorry, the picture I raised this error is no longer available The previous error was: Now the error is: Theoretically, I should get two exceptions for executing the file above |
It turned out that the file extension in question was The error is still I'm sorry that I didn't keep the pictures. |
I did a search for the code
As for why the cache problem occurs If I could reproduce the situation it would look something like this
That is, I feel that because the output path is the same, the exception is cached. And I restart the process, restart the machine whatever the output path is |
I figured out a way to export normal images to the Steadily reproduces the error, and the error record still exists, that is If I don't change the output_path, I will never be able to output to it. |
I'll post my test code and execution results
|
There's a lot going on here. Perhaps you could create a standalone repo with code and images that allows someone else to reproduce. Please try to make it as minimal as possible. |
@lovell My main question now is where is the cache |
I can now replicate the mistake at will and figure out what the problem is.
The RE is wrong, is too loose and the match is too long Problems occurred with the three paths because the directory section had "." 3hoyz5dcx8efl4dypgnj2k
line 32
// line 78 |
Well done for tracking this down, thank you. Happy to accept a PR to fix this if you're able. |
Although RE is less rigorous, it can still be used I suggest
|
v0.32.2 now available, thank you for the PR. |
JP2 output requires libvips with support for OpenJPEG
Now the
path_input
is fixed, but the picture itself is changed.If no errors occur, the execution is normal,The output changes with the input,
The cache cleanup is valid.
If an error occurs, the result is cached unless the
output path
is changed.for example
JP2 output requires libvips with support for OpenJPEG
path_input
the picture itself is changed and is no longer jp2,Errors will occur.I use a different
path_input
, error is always going to happen.Util
path_output
change.And the cache isn't just in memory. Restart the process and restart the machine errors still exist.
The text was updated successfully, but these errors were encountered: