Open fonsp opened 4 years ago
This should fix the PNG MIME issue, and mean the user just needs ImageIO, as long as only PNGs are used https://github.com/JuliaIO/ImageIO.jl/pull/7
I agree that FileIO's compound error messages are a bit tough.. but as long as the packages are interacting properly (which they should by design.. this was an oversight) the current error message format should generally be nice and friendly. https://github.com/JuliaIO/ImageIO.jl/issues/6 was hopefully a rare bug
As for Making the install process simpler. Perhaps Images.jl
could take on a ImageIO.jl
dep? @timholy ?
To clarify, you don't need to import the whole Images
stack to show an image. It is 1) ImageShow
2) PNG backend ImageMagick
or ImageIO
that you need.
I am pretty lost in all the Image packages - where should this code live?
@fonsp I believe you're suggesting 1) implementing BMPFiles
as a pure Julia io backend for BMP files, 2) (optionally) registering it in FileIO
and 3) dispatch image/bmp
mime to BMPFiles in ImageShow
(similar to how we did for image/png
). Directly hosting those codes here doesn't fit the current design well.
Perhaps Images.jl could take on a ImageIO.jl dep?
There's a proposal for this https://github.com/JuliaImages/Images.jl/issues/824 I think we just need some agreement on what should be installed by default. ImageMagick
has more features and I feel it should be the default option, but yeah, ImageIO is a lot faster than that for PNG files.
Aha, do I understand correctly that:
Images
+ ImageIO
should be enough to show(io, png, i)
an image, but right now there is a bug (https://github.com/JuliaIO/ImageIO.jl/issues/6) that you need Images
+ ImageIO
+ ImageMagick
?
Thanks for clarifying the package structure. But the only reason that I want to write it is to make the code
using Images; Gray.(rand(4,4))
work in an env that only has Images
(+deps) installed, and possibly to make the base package install more lightweight. Would BMPFiles
do that?
I didn't watch closely to ImageIO
, my best guess is that you just hit a bug that ImageIO overlooks.
If it's only for displaying an image by using Images; Gray.(rand(4,4))
, then Images + ImageIO
should be sufficient and we don't need to support image/bmp
mime at all. The most lightweight dependency for this purpose is ImageShow + ImageIO
. To get color objects such as Gray
, N0f8
things, you can also add ImageCore
to your project, which reexports Colors
and FixedPointNumbers
.
If we want to support image/bmp
mime (but I guess you don't mean to it), then there're two options: 1) use ImageMagick 2) implement a pure Julia one.
FYI, there's a section in the docs explaining how to choose between different IO backends. Note that ImageIO
has higher priority to ImageMagick
in FileIO
's dispatch system.
If all the interest is to get that bug fixed, then probably we can close this issue and move the future discussion to https://github.com/JuliaIO/ImageIO.jl/pull/7?
Hi all,
Images.jl
can be a bit tough to work with, because you need to manually install the dependenciesImageIO
andImageMagick
for the show methods to work, and the error messages are somewhat cryptic (https://github.com/JuliaIO/ImageIO.jl/issues/6).A solution could be to write a
show
method forimage/bmp
- the file format is so simple that it can be written in Julia, and it would work without any additional dependencies, on all platforms.Here's a BMP encoder that I wrote for greyscale images:
https://github.com/lukavdplas/pluto-notebooks/blob/master/svd.jl#L318-L356
It could be modified to also add support for RGB images - this is just a different header.
My goal is to make this basic Pluto notebook work:
The MIME priority of Pluto display system is here: https://github.com/fonsp/Pluto.jl/blob/v0.11.7/src/runner/PlutoRunner.jl#L201 Currently, PNG is prioritized over BMP. I would like to keep that ordering, but if that's not possible, then I can consider moving BMP before PNG.
I am pretty lost in all the Image packages - where should this code live?