6 ms·

If you're scanning a long document to a PDF, compression makes a lot of sense. It's the difference between being able to email the PDF as an attachment and havi

If you're scanning a long document to a PDF, compression makes a lot of sense. It's the difference between being able to email the PDF as an attachment and having to find a place to put the file online.

algorias 13y ago
Exactly, and that is why there should be a compression step on the code path that handles the paper -> pdf case. This doesn't make any sense in a paper -> paper case, however, as any electronic version of the image will only be stored internally, for a very brief time.
lostlogin 13y ago
It is amazing the things people expect to be emailed. Can you email me the MRI scan? It's over 1500 images. Can you email it?
- sneak 13y ago
  It's amazing to me the engineers who refuse to update their worldviews about normal people's mental models for "sending data" that still get amazed by this. The size of the files or the number of them are totally irrelevant.
  - lotharbot 13y ago
    Normal people seem to get that it's considerably harder to ship a barn than a letter, and that if you want to move a barn you use a specialty service rather than the post office. The size and number of files are and should be totally relevant even to "normal" people. When someone asks for something in e-mail, it's perfectly reasonable to say "no, it's much too big" and expect them to understand.
    - michaelt 13y ago
      I think we can all agree that e-mails should have finite size - it's not a very good protocol for transferring multi-gigabyte files, for sure! Where we would disagree is where that limit should be drawn. I've seen systems in this day and age that fail in the face of e-mails as small as 5 megabytes (e.g. Yahoo Popgate) which IMHO is far too low - but evidently some sysadmins disagree with me!
      - ams6110 13y ago
        Opinions run the gamut. I'm firmly in the "email should be plain text" camp but realized that battle was lost long ago.
      - PeterisP 13y ago
        Email size is a technical issue that shouldn't be limiting (or even visible) to the end user. If an end user wants to send a multigigabyte file to another user's email address - why not? The email client could launch a background upload process and email a link to get that file by, say, bittorrent... Some protocol extensions and software support would be needed, but that can be done and, as users need it, probabpy should be done.
        wiml 13y ago
        Oh, the protocols are already in place; consider RFC2017. Sending a link to something (even wrapped in a nice ui and container) has pretty different semantics from actually sending the something, though.
    - jl6 13y ago
      It would be helpful if file managers gave better cues as to file size. A barn is obviously different to a letter, but a one byte file is normally given the same icon as a one terabyte file.
    - epistasis 13y ago
      But we're not dealing with barns or letters or any physical object, we're dealing with abstract systems where the physics are much more flexible and changeable. It's important to change our computer systems to work for us, rather than attempting to change people to adapt to the computer systems. We should discard those systems that can not adapt to humanity, as they are of little worth in the long run. When somebody says, "can you email it to me" they mean, grant access to the data via their centralized messaging system, their email. There are many ways to make that happen, one of which is an attachment, another of which is linking to the content, but the key is to make sure that it's low friction and takes very little time or clicks to get access from the email.
      - lotharbot 13y ago
        There are some pieces of content for which it's entirely impractical to "grant access via e-mail". On occasion people ask to be e-mailed extremely large blocks of data, where it would literally be faster to burn it to a pile of DVDs and then FedEx them than to upload-and-then-download the data. Depending on the size of the medical images mentioned in a previous post, that might actually be the case in that circumstance. It's a failure of technology when it's difficult to send ordinary-sized files like a few photos or a couple pages of documents. But it's a failure of people when they don't recognize the possibility that some types of data (video, large numbers of images, scientific research data, whole databases) simply can't be sent quickly, yet they fail to plan ahead to gain access. (I've also entirely skirted the issue of "some data should have its access restricted physically"...)
        ams6110 13y ago
        Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway Andrew Tanenbaum
        epistasis 13y ago
        > But it's a failure of people when they don't recognize the possibility that some types of data (video, large numbers of images, scientific research data, whole databases) simply can't be sent quickly, yet they fail to plan ahead to gain access. (I've also entirely skirted the issue of "some data should have its access restricted physically"...) I disagree vehemently with that attitude, and I have to deal with it everyday. In my field, >50% of the data we receive is transferred by overnight courier of hard drives due to quantity of data. It's a crappy attitude to blame people for having to learn that, and in an ideal world we'd share it via access granted by email. People should not be blamed for not understanding that, our infrastructure should be blamed for not supporting 10Gb everywhere, and cheap access to 40Gb+ on long-distance connections. Nothing is helped by blaming people, and relationships can be harmed by doing that. But we can change the technology. As a side note, DVDs? Really? They're incredibly slow at data transfer once you have them in hand, the tiny size of a DVD requires tricky archive spanning methods, and optical discs are flaky technology all around. Hard drives or LTO-5/6 all the way.
  - lostlogin 13y ago
    Just to make it clear, I'm not an engineer (I'd like to be good enough to be considered one, but that's a long way off). I'm more of an enthusiastic amateur who knows enough to badly break things. And the people who ask most frequently ask are ortho surgeons with a patient asleep on the table. Anyone who waits until that late in the piece then asked for a 1.5gig email becuase they weren't organised enough to sort out access to images in the 3 month lead up to an operation is not a normal person.
    - boas 13y ago
      We developed an easy way to email and collaboratively view CT or MRI studies. http://www.claripacs.com http://www.claripacs.com.
      - lostlogin 13y ago
        Thanks, I'll be looking into that.
- Retric 13y ago
  Emailing the file or emailing a link to the file is just as useful. As long as you have an encrypted document sharing capability you should be able to say sure to just about anything. PS: Granted that's assuming fast networks. For 80+ Gig VM's sending a removable drive is often faster.
  - jamespo 13y ago
    For a lot of end users, if it's not a proper attachment no end of grief is caused. And encryption and file hosting causes more hassle in enterprise environments with unforgiving compliance policies.

algorias 13y ago

Exactly, and that is why there should be a compression step on the code path that handles the paper -> pdf case. This doesn't make any sense in a paper -> paper case, however, as any electronic version of the image will only be stored internally, for a very brief time.

lostlogin 13y ago

It is amazing the things people expect to be emailed. Can you email me the MRI scan? It's over 1500 images. Can you email it?

sneak 13y ago
It's amazing to me the engineers who refuse to update their worldviews about normal people's mental models for "sending data" that still get amazed by this. The size of the files or the number of them are totally irrelevant.
- lotharbot 13y ago
  Normal people seem to get that it's considerably harder to ship a barn than a letter, and that if you want to move a barn you use a specialty service rather than the post office. The size and number of files are and should be totally relevant even to "normal" people. When someone asks for something in e-mail, it's perfectly reasonable to say "no, it's much too big" and expect them to understand.
  - michaelt 13y ago
    I think we can all agree that e-mails should have finite size - it's not a very good protocol for transferring multi-gigabyte files, for sure! Where we would disagree is where that limit should be drawn. I've seen systems in this day and age that fail in the face of e-mails as small as 5 megabytes (e.g. Yahoo Popgate) which IMHO is far too low - but evidently some sysadmins disagree with me!
    - ams6110 13y ago
      Opinions run the gamut. I'm firmly in the "email should be plain text" camp but realized that battle was lost long ago.
    - PeterisP 13y ago
      Email size is a technical issue that shouldn't be limiting (or even visible) to the end user. If an end user wants to send a multigigabyte file to another user's email address - why not? The email client could launch a background upload process and email a link to get that file by, say, bittorrent... Some protocol extensions and software support would be needed, but that can be done and, as users need it, probabpy should be done.
      - wiml 13y ago
        Oh, the protocols are already in place; consider RFC2017. Sending a link to something (even wrapped in a nice ui and container) has pretty different semantics from actually sending the something, though.
  - jl6 13y ago
    It would be helpful if file managers gave better cues as to file size. A barn is obviously different to a letter, but a one byte file is normally given the same icon as a one terabyte file.
  - epistasis 13y ago
    But we're not dealing with barns or letters or any physical object, we're dealing with abstract systems where the physics are much more flexible and changeable. It's important to change our computer systems to work for us, rather than attempting to change people to adapt to the computer systems. We should discard those systems that can not adapt to humanity, as they are of little worth in the long run. When somebody says, "can you email it to me" they mean, grant access to the data via their centralized messaging system, their email. There are many ways to make that happen, one of which is an attachment, another of which is linking to the content, but the key is to make sure that it's low friction and takes very little time or clicks to get access from the email.
    - lotharbot 13y ago
      There are some pieces of content for which it's entirely impractical to "grant access via e-mail". On occasion people ask to be e-mailed extremely large blocks of data, where it would literally be faster to burn it to a pile of DVDs and then FedEx them than to upload-and-then-download the data. Depending on the size of the medical images mentioned in a previous post, that might actually be the case in that circumstance. It's a failure of technology when it's difficult to send ordinary-sized files like a few photos or a couple pages of documents. But it's a failure of people when they don't recognize the possibility that some types of data (video, large numbers of images, scientific research data, whole databases) simply can't be sent quickly, yet they fail to plan ahead to gain access. (I've also entirely skirted the issue of "some data should have its access restricted physically"...)
      - ams6110 13y ago
        Never underestimate the bandwidth of a station wagon full of tapes hurtling down the highway Andrew Tanenbaum
      - epistasis 13y ago
        > But it's a failure of people when they don't recognize the possibility that some types of data (video, large numbers of images, scientific research data, whole databases) simply can't be sent quickly, yet they fail to plan ahead to gain access. (I've also entirely skirted the issue of "some data should have its access restricted physically"...) I disagree vehemently with that attitude, and I have to deal with it everyday. In my field, >50% of the data we receive is transferred by overnight courier of hard drives due to quantity of data. It's a crappy attitude to blame people for having to learn that, and in an ideal world we'd share it via access granted by email. People should not be blamed for not understanding that, our infrastructure should be blamed for not supporting 10Gb everywhere, and cheap access to 40Gb+ on long-distance connections. Nothing is helped by blaming people, and relationships can be harmed by doing that. But we can change the technology. As a side note, DVDs? Really? They're incredibly slow at data transfer once you have them in hand, the tiny size of a DVD requires tricky archive spanning methods, and optical discs are flaky technology all around. Hard drives or LTO-5/6 all the way.
- lostlogin 13y ago
  Just to make it clear, I'm not an engineer (I'd like to be good enough to be considered one, but that's a long way off). I'm more of an enthusiastic amateur who knows enough to badly break things. And the people who ask most frequently ask are ortho surgeons with a patient asleep on the table. Anyone who waits until that late in the piece then asked for a 1.5gig email becuase they weren't organised enough to sort out access to images in the 3 month lead up to an operation is not a normal person.
  - boas 13y ago
    We developed an easy way to email and collaboratively view CT or MRI studies. http://www.claripacs.com http://www.claripacs.com.
    - lostlogin 13y ago
      Thanks, I'll be looking into that.
Retric 13y ago
Emailing the file or emailing a link to the file is just as useful. As long as you have an encrypted document sharing capability you should be able to say sure to just about anything. PS: Granted that's assuming fast networks. For 80+ Gig VM's sending a removable drive is often faster.
- jamespo 13y ago
  For a lot of end users, if it's not a proper attachment no end of grief is caused. And encryption and file hosting causes more hassle in enterprise environments with unforgiving compliance policies.