Uploaded image for project: 'Image Archives'
  1. Image Archives
  2. IMG-33

Cover art archive should return height and width of full image in its JSON response

    • Icon: Improvement Improvement
    • Resolution: Unresolved
    • Icon: Normal Normal
    • None
    • None

      In a similar way to what is doing Discogs (e.g. http://api.discogs.com/releases/1508127)

      This would be both convenient and would save bandwidth since currently you have to download the image to get its size,
      and then thrown it away if you consider it's too small for your usage.

          [IMG-33] Cover art archive should return height and width of full image in its JSON response

          ROpdebee added a comment -

          Spot on! The main thing the script does it creating a HTML img element and polling until the browser sets the naturalWidth and naturalHeight properties, and cancelling the image load afterwards. All of this usually happens quite quickly, since the browser can get the necessary information from the image file's headers, without having to download an entire 40MB PNG. Some additional things it does are getting the file size from IA's metadata API, and in case of PDF files, the page count by counting the number of files in a ZIP file derived by the IA. The script also has some caching functionality with IndexedDB to save some time on subsequent visits.

          All that being said, I'm not sure whether any of this could help towards including this information in the CAA API responses, unless it's implemented on the server side (which, as I discussed in MBS-6641, seems undesirable). And even if it does get implemented on the server side, there would probably be better ways to do it, since you'd no longer be constrained to a browser environment.

          However, as far as I know, there's nothing technically blocking this from being integrated on the client side. Integrating this into MBS' client side would unblock MBS-5507, MBS-6641, MBS-4701, and MBS-5139, as well as possibly other tickets. Unfortunately, I currently don't have the bandwidth to integrate it myself (and I don't know React), but the userscript code is MIT-licensed, so anyone is free to reuse whatever parts might be useful, and I'd of course be happy to help where I can. The only thing I'd ask for is some attribution.

          ROpdebee added a comment - Spot on! The main thing the script does it creating a HTML img element and polling until the browser sets the naturalWidth and naturalHeight properties, and cancelling the image load afterwards. All of this usually happens quite quickly, since the browser can get the necessary information from the image file's headers, without having to download an entire 40MB PNG. Some additional things it does are getting the file size from IA's metadata API , and in case of PDF files, the page count by counting the number of files in a ZIP file derived by the IA . The script also has some caching functionality with IndexedDB to save some time on subsequent visits. All that being said, I'm not sure whether any of this could help towards including this information in the CAA API responses, unless it's implemented on the server side (which, as I discussed in MBS-6641 , seems undesirable). And even if it does get implemented on the server side, there would probably be better ways to do it, since you'd no longer be constrained to a browser environment. However, as far as I know, there's nothing technically blocking this from being integrated on the client side. Integrating this into MBS' client side would unblock MBS-5507 , MBS-6641 , MBS-4701 , and MBS-5139 , as well as possibly other tickets. Unfortunately, I currently don't have the bandwidth to integrate it myself (and I don't know React), but the userscript code is MIT-licensed, so anyone is free to reuse whatever parts might be useful, and I'd of course be happy to help where I can. The only thing I'd ask for is some attribution.

          Looking at the code (https://github.com/ROpdebee/mb-userscripts/blob/main/src/mb_caa_dimensions/dimensions.ts) it seems to load the image, but abort the load as soon as enough data is available to know the dimension? ROpdebee could tell us more of course

          Nicolás Tamargo added a comment - Looking at the code ( https://github.com/ROpdebee/mb-userscripts/blob/main/src/mb_caa_dimensions/dimensions.ts ) it seems to load the image, but abort the load as soon as enough data is available to know the dimension? ROpdebee could tell us more of course

          Aerozol added a comment -

          There is a MusicBrainz userscript, Display CAA image dimensions, that displays image dimensions. It can't be loading the full images locally because it will display dimensions for very large images very quickly.

          Aerozol added a comment - There is a MusicBrainz userscript, Display CAA image dimensions , that displays image dimensions. It can't be loading the full images locally because it will display dimensions for very large images very quickly.

          Kuno Woudt added a comment -

          Resolution can be determined client-side once MBS-4376 ships (proof-of-concept code attached), and could then also be submitted along with the image in the "Add Cover Art" edit. If we want to store this anywhere other than the comment, we probably should add database fields for image width/height in the next schema change.

          Kuno Woudt added a comment - Resolution can be determined client-side once MBS-4376 ships (proof-of-concept code attached), and could then also be submitted along with the image in the "Add Cover Art" edit. If we want to store this anywhere other than the comment, we probably should add database fields for image width/height in the next schema change.

          nikki added a comment -

          See what Ian and Ollie already said. The whole thing is deliberately designed so that the images will never touch MusicBrainz's servers, so that's (still) not an option.

          nikki added a comment - See what Ian and Ollie already said. The whole thing is deliberately designed so that the images will never touch MusicBrainz's servers, so that's (still) not an option.

          jesus2099 added a comment - - edited

          Depending on how we manage MBS-4376, it could allow us to upload picture to MBS first, store its height×width before eventually upload it from MBS to CAA last.
          But the most cleanest solution is still that CAA publicise this information, as ianmcorvidae said.

          jesus2099 added a comment - - edited Depending on how we manage MBS-4376 , it could allow us to upload picture to MBS first, store its height×width before eventually upload it from MBS to CAA last. But the most cleanest solution is still that CAA publicise this information, as ianmcorvidae said.

          nikki added a comment -

          Doesn't that have the same problem as CAA-28?

          nikki added a comment - Doesn't that have the same problem as CAA-28 ?

          Robert Kaye added a comment -

          We need to look at how to handle this on the client side and send the information with our POST. This is hard to solve on the IA side of things.

          Robert Kaye added a comment - We need to look at how to handle this on the client side and send the information with our POST. This is hard to solve on the IA side of things.

          The first option is sadly not an option, as we are not going to touch binary image data. The only solution here is for the IA to get this data to us, somehow.

          Oliver Charles added a comment - The first option is sadly not an option, as we are not going to touch binary image data. The only solution here is for the IA to get this data to us, somehow.

          Ian McEwen added a comment -

          I don't think we can do this without downloading the images somewhere – but if we do it's presumably easy to add this to the indexer. The other option is perhaps adding it to the IA's system for the file listing and file metadata (e.g. http://ia601202.us.archive.org/12/items/mbid-9f76d9c8-2aa6-452d-9a69-1881e6726f9f/mbid-9f76d9c8-2aa6-452d-9a69-1881e6726f9f_files.xml and http://ia701202.us.archive.org/12/items/mbid-9f76d9c8-2aa6-452d-9a69-1881e6726f9f/mbid-9f76d9c8-2aa6-452d-9a69-1881e6726f9f_meta.xml ). I don't know the details for that second option, of course.

          Ian McEwen added a comment - I don't think we can do this without downloading the images somewhere – but if we do it's presumably easy to add this to the indexer. The other option is perhaps adding it to the IA's system for the file listing and file metadata (e.g. http://ia601202.us.archive.org/12/items/mbid-9f76d9c8-2aa6-452d-9a69-1881e6726f9f/mbid-9f76d9c8-2aa6-452d-9a69-1881e6726f9f_files.xml and http://ia701202.us.archive.org/12/items/mbid-9f76d9c8-2aa6-452d-9a69-1881e6726f9f/mbid-9f76d9c8-2aa6-452d-9a69-1881e6726f9f_meta.xml ). I don't know the details for that second option, of course.

            Unassigned Unassigned
            murdos Aurélien Mino
            Votes:
            13 Vote for this issue
            Watchers:
            12 Start watching this issue

              Created:
              Updated:

                Version Package