*** Issue: ***

• The test fixtures can be simplified even further as there is a pattern, see below:

  @gh_raw_url "https://raw.githubusercontent.com/stephenmoloney/fastimage/master/priv/"
  @jpg_url "#{@gh_raw_url}test.jpg"
  @jpg_url_with_query "https://avatars0.githubusercontent.com/u/12668653?v=2&s=40"
  @jpg_with_redirect "http://seanmoloney.com/images/cover1.jpg"
  @png_url "#{@gh_raw_url}test.png"
  @gif_url "#{@gh_raw_url}test.gif"
  @bmp_url "#{@gh_raw_url}test.bmp"
  @webp_vp8l_url "#{@gh_raw_url}webp_vp8l.webp"
  @webp_vp8_url "#{@gh_raw_url}webp_vp8.webp"
  @webp_vp8x_url "#{@gh_raw_url}webp_vp8x.webp"

  @jpg_file "./priv/test.jpg"
  @png_file "./priv/test.png"
  @gif_file "./priv/test.gif"
  @bmp_file "./priv/test.bmp"
  @webp_vp8_file "./priv/test_vp8.webp"
  @webp_vp8x_file "./priv/test_vp8x.webp"
  @webp_vp8l_file "./priv/test_vp8l.webp"

  @jpg_binary File.read!(@jpg_file)
  @png_binary File.read!(@png_file)
  @gif_binary File.read!(@gif_file)
  @bmp_binary File.read!(@bmp_file)
  @webp_vp8_binary File.read!(@webp_vp8_file)
  @webp_vp8x_binary File.read!(@webp_vp8x_file)
  @webp_vp8l_binary File.read!(@webp_vp8l_file)

add tests for binary types

add tests vs some of the most likely potential error cases

I've spend a few hours trying to reconcile dependencies. The issue is coming from gun requiring cowlib 1.3.0, while Phoenix is on cowboy ~> 1.0.0 which requires cowlib ~> 1.0.0 and is incompatible if you try to force 1.3.0 on it.
With lower gun version that works with cowlib ~> 1.0.0 your lib breaks.
With cowlib ~> 1.0.0, override: true gun compilation break.
In the end I got it to work with my gun fork that relaxes cowlib dependency.

     {:cowlib, "~> 1.0.0", manager: :rebar, override: true},
     {:gun, github: "kagux/gun", override: true},
     {:ranch, "~> 1.2.0", manager: :rebar, override: true},

But I can't be sure of all consequences. Could be that issue I reported before is related to this change.
I think it would benefit your lib a lot to be compatible with latest version of Phoenix.

in Fastimage.File, wrap in try catch so that error is catched and returned as Fastimage.Error.

  @spec recv(String.t(), :file) :: {:ok, binary(), File.Stream.t()} | {:error, Error.t()}
  defp recv(file_path, :file) do
#    {:ok, _data, _file_stream} =
#    try do
      file_path
      |> File.stream!([:read, :compressed, :binary], @file_chunk_size)
      |> stream_chunks(1, {0, <<>>, file_path}, 0, 0)
#    catch
#    end
  end

introduce Fastimage.info function with both size and type in one pass

I open an issue here for reference.

With hackney 1.11 I have a deadlock when I use fastimage, all details here: benoitc/hackney#447 (comment)

I am not sure if the bug is in fastimage or hackney itself, but as I don't have the bug with hackney 1.9 I thought it might be hackney.

• returned errors, some degree of tidy up needed here for errors bubbling up from private functions
• make multiple versions of :hackney acceptable
• support binaries in addition to a file path or uri
• change return image type return types to atoms @type image_types :: :bmp | :gif | :jpg | :png
• change errors to Elixir Exceptions - eg UnknownTypeError
• introduce type -> {:ok, type} and size -> {:ok, size}, type!, and size! function formats [will need to change raise(inspect(error)) -> raise(error) ]
• credo linting
• ensure close_stream in all relevant locations
• added new Fastimage.info function
• add options to type/1, size/1 and info/1 to allow manual overrides on
  the otherwised fixed values for stream_timeout, max_redirect_retries and
  max_error_retries

Description:

• review line 66 of the Parser module (# get more data if less that 4 bytes remaining)
• is it necessary and functioning as expected?

I'm trying to process this image via Fastimage.size(image_path):

But it returns me exception

iex(3)> Fastimage.size(path)
** (MatchError) no match of right hand side value: ""
    (fastimage) lib/fastimage.ex:257: Fastimage.matching_byte/2
    (fastimage) lib/fastimage.ex:247: Fastimage.next_bytes_until_match/2
    (fastimage) lib/fastimage.ex:159: Fastimage.parse_jpeg/6
    (fastimage) lib/fastimage.ex:190: Fastimage.parse_jpeg/6
    (fastimage) lib/fastimage.ex:187: Fastimage.parse_jpeg/6
    (fastimage) lib/fastimage.ex:190: Fastimage.parse_jpeg/6
    (fastimage) lib/fastimage.ex:187: Fastimage.parse_jpeg/6
    (fastimage) lib/fastimage.ex:190: Fastimage.parse_jpeg/6
    (fastimage) lib/fastimage.ex:43: Fastimage.size/1

What should I do here?

Fastimage.size("https://raw.githubusercontent.com/myFree/public_eg/main/SampleBMP.bmp")
{:ok, %Fastimage.Dimensions{height: 0, width: 2560}}

The height of the image is 1920px

The files priv/test_extended.webp and priv/test_lossy.webp are same the type of webp. You will notice that the webp_vp8x function is no longer covered https://coveralls.io/builds/19327754/source?filename=lib%2Ffastimage%2Fparser.ex#L251

TODO - add option for exif information parsing

• See the Parser module

consider adding Stream.Acc to the Fastimage.Error struct output

handle :nxdomain error when no internet connection

Feature to be added

• Follow images behind a redirect

Description

• failing build on hackney version 1.10.1

• failing build example: https://travis-ci.org/stephenmoloney/fastimage/jobs/345947534#L746

no match of right hand side value: {:error, :normal}

open issue on benoit/hackney for this

Solution

• not sure, would need to investigate in :hackney upstream. Also, version 1.11.0 is released so perhaps wait for changes on later versions

Keep dependencies as limited as possible. So

• Remove dependency on Og
• Check latest releases of :hackney and whether it should be updated.

hey,

first of all, thanks a lot for your work on this library!
I wanted to use it to get dimensions for multiple images and noticed that results get mixed up. As in I request sizes for images [...., A, ... B, .... ] consecutively and often image B size is in fact coming from image A. with delay added between calls less images get affected until it's big enough to disappear completely.
do you have any ideas why this could be happening?

Hi man, firstly thanks for your work! I've been using FastImage in one of my apps in production.

Just curious about your thoughts on changing the API to more inline with other similar Elixir behavior.

FastImage.size() -> {:ok, %{width: _, height: _}} 

FastImage.size!() -> {%width: _, height: _}}

Definitely down to send in a PR with this change. Cheers.

make various versions of hackney optional

Perhaps introduce a more sophisticated retry mechanism with backoff...
right now basically retries a few times and fails.

Issue:

The different webp formats is not obvious, provide links in code which describe the differences

https://developers.google.com/speed/webp/docs/riff_container#extended_file_format

• support binaries in addition to a file path or uri