Re: Rev cannot open my jpeg ! - and some serious thinking

[Francis Nugent Dixon]

Hi from Paris,

I bought a  Sony-DSC-F717 a couple of years back - went into my list  
of "Best-Spent Money" items - gives beautiful photos of 5 Megapixels  
(I never change the setting).
The photos each represent about 2 MB, and with that, I can print out a  
high quality photo on A4, reasonable quality on A3. My close-up photos  
of flowers would make many photographers green with envy. What I mean  
is that a 5 megapixel/2 MB photo is enough for me, and I am a stickler  
for quality. I have many Rev stacks that display hundreds of jpg  
photos, and so I had to scale down my photos for rapid display and  
reduced disk space.

I use GraphicConvertor (Mac) - also on my "Best-Spent Money" list. You  
can batch scale-down a complete folder, to the size of photos you want.

Just in case I ever want higher quality (and I have more than 30 years  
of 35mm negatives to examine), I also have a Nikon DiMage 35mm  
scanner, and I CAN scan the negatives up to 100Mb files (what for, I  
will never know !)

I scan my BEST colour negatives to about 20 MB, and I CAN print them  
up to 1.5 metres x 1 metre posters - much more than the average Yogi  
Bear requirements.

The latest cameras are providing more than 15 Megapxels, and  
technology will take us much higher within a very short time ! I'm not  
sure what that represents in MB, but it certainly is a lot. I'm also  
unsure of the need for cameras of this quality for the average user.

Unless you are a professional, you don't need photos of this quality,  
so why take them ?

My next camera (I'm in no hurry) will probably clock in at 25  
Megapixels, and I will need to upgrade seriously from my iMac with 1TB  
in order to be able to store and treat my photos. Maybe 1 photo in a  
thousand will require that precision (if I want to push it to a  
poster), but I will have to take ALL of my photos at that precision to  
do so ! I'll need many TBs to store all of them, and one hell of a  
processor ! Don't you think that this is just a little bit "overkill",  
remembering, of course that the lifetime of an average photo is about  
the same as that of a household fly ! I have three photo categories -  
1) photos for the masses 2) photos for those who appreciate photos,  
and 3) photos I am proud of. I examine all my photos and decide which  
category it goes into, AND SCALE THEM DOWN if they are for categories  
1 and 2, THROWING AWAY the originals afterwards. Why waste disk  
space ? Did you really want all those megapixels ?

Which brings me to the forum question "I've got photos of 13  
megapixels that Rev can't handle". Who wants to push the (Revolution)  
envelope that far ?

Let's assume that you are a professional. Don't use Revolution to  
solve this problem, it wasn't designed for that - use a professional  
photo program like GraphicConvertor. Of course you can alway put in a  
bug report, but seriously, don't you think that there are more  
important issues to be solved with Revolution ?

If I want to knock a nail in, I use a hammer, not my shoe (which was  
designed for protecting my foot). Revolution is fantastic. It does so  
many things. Why ask it to wake you in the morning with a hot coffee ?

FWIW

-Francis

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Ian Wood-3]

On 27 Jun 2009, at 17:45, Francis Nugent Dixon wrote:

> Which brings me to the forum question "I've got photos of 13  
> megapixels that Rev can't handle". Who wants to push the  
> (Revolution) envelope that far ?

People writing tools for photographers? In my case a photographer  
writing tools for other photographers. ;-)

> Let's assume that you are a professional. Don't use Revolution to  
> solve this problem, it wasn't designed for that - use a professional  
> photo program like GraphicConvertor. Of course you can alway put in  
> a bug report, but seriously, don't you think that there are more  
> important issues to be solved with Revolution ?

Depends. If you want to develop an app that deals with photos in  
almost any way (web gallery generation, digital asset management,  
animation, slideshows/presentations) then at this point in time you  
CANNOT do this in Rev* because the vast majority of consumer cameras  
now produce JPEGs that Rev can't handle.

> If I want to knock a nail in, I use a hammer, not my shoe (which was  
> designed for protecting my foot). Revolution is fantastic. It does  
> so many things. Why ask it to wake you in the morning with a hot  
> coffee ?

Because it's a whole field of apps that Rev would otherwise excel in  
as a development tool, apart from this one bug affecting Rev on OS X.

Ian


*Short of jumping through hoops by using large numbers of QT Player  
objects, or using SIPS or similar command line tools to make  
downscaled versions of files etc.
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[François Chaplais-3]

Le 27 juin 09 à 18:45, Francis Nugent Dixon a écrit :

> Hi from Paris,
>
> I bought a  Sony-DSC-F717 a couple of years back - went into my list  
> of "Best-Spent Money" items - gives beautiful photos of 5 Megapixels  
> (I never change the setting).
> The photos each represent about 2 MB, and with that, I can print out  
> a high quality photo on A4, reasonable quality on A3. My close-up  
> photos of flowers would make many photographers green with envy.  
> What I mean is that a 5 megapixel/2 MB photo is enough for me, and I  
> am a stickler for quality. I have many Rev stacks that display  
> hundreds of jpg photos, and so I had to scale down my photos for  
> rapid display and reduced disk space.
>
> I use GraphicConvertor (Mac) - also on my "Best-Spent Money" list.  
> You can batch scale-down a complete folder, to the size of photos  
> you want.
>
> Just in case I ever want higher quality (and I have more than 30  
> years of 35mm negatives to examine), I also have a Nikon DiMage 35mm  
> scanner, and I CAN scan the negatives up to 100Mb files (what for, I  
> will never know !)
>
> I scan my BEST colour negatives to about 20 MB, and I CAN print them  
> up to 1.5 metres x 1 metre posters - much more than the average Yogi  
> Bear requirements.
>
> The latest cameras are providing more than 15 Megapxels, and  
> technology will take us much higher within a very short time ! I'm  
> not sure what that represents in MB, but it certainly is a lot. I'm  
> also unsure of the need for cameras of this quality for the average  
> user.
>
> Unless you are a professional, you don't need photos of this  
> quality, so why take them ?

If the optics are up to the task, the the Hi Res eliminates any need  
for zooming; you do the editing on the computer.

François, who used to develop his argentic photos in the 70's and  
remembers these high grain, 400 ASA Ilford films...
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Sarah Reichelt-2]

> Which brings me to the forum question "I've got photos of 13 megapixels that
> Rev can't handle". Who wants to push the (Revolution) envelope that far ?

Me for one. My app Pic-a-POD <http://www.troz.net/Pic-a-POD/> suffers
greatly from this problem as more and more large images appear on the
internet. At the moment I am forced to check for images with more than
4000 pixels on any side, and if so, I just have to show a notice
saying that the image is too big to display. This is not always
correct as a tall thin image can work but I haven't been able to work
out an exact algorithm for telling what will work and what won't. Even
more unfortunately, there is no error reported when Rev tries to
display an image that is too big - you just get horrible grey streaks
or some other form of distortion.

As consumer level cameras produce larger and larger images, the
prevalence of such images will only increase and I think it is
unrealistic to say that people shouldn't be using such large images.
If their cameras can do it, why would they not take images at the
highest possible quality? This is not a problem that is going to go
away and I think RunRev need to give some serious thought to fixing
the image object.

Cheers,
Sarah
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Dom-2]

Sarah Reichelt <[hidden email]> wrote:

> Me for one. My app Pic-a-POD <http://www.troz.net/Pic-a-POD/> suffers
> greatly from this problem as more and more large images appear on the
> internet. At the moment I am forced to check for images with more than
> 4000 pixels on any side, and if so, I just have to show a notice
> saying that the image is too big to display.

+1

Pic-a-POD sits on my desktop :-)

"POD" web sites do change their format from time to time, though...
For instance, National Geographic leads to a "Picture is not in the
correct format" warning.
and Wikipedia furnishes regurlarly too big images!

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Mike Markkula]

Sarah,

The script below will at least treat the user properly.

I too wish wish wish Rev would remove the 4095 pixel width limit!
(there is no height limit) As is, its a deal breaker for any serious
app in the photography arena.

Mike Markkula

--------------------------------------------------
function importImageFile theFilePath
   -- attempt to create image given its file path
   -- if successful, return its id,  if not, return empty
   -- Rev can import images wider than 4095 pixels,
   -- but can¹t display them properly

   set the itemDelimiter to "/"
   put the last item of theFilePath into theImageName

   try
      import paint from file theFilePath
      put the ID of the last image into theImageID
      if the width of image ID theImageID > 4095 then
         delete image ID theImageID
         put empty into theImageID
         beep
         answer "Sorry, I can't open " & quote & theImageName & quote & \
         " because it's wider than 4095 pixels."
       end if
   catch anyError
      if anyError is not empty then
         delete image ID theImageID
         put empty into theImageID
         beep
         answer "Sorry, I can't import " & quote & theImageName & quote & \
         " because " & anyError & "."
      end if
   end try

   return theImageID
end importImageFile
-------------------------------------

On 6/27/09 5:33 PM, "Sarah Reichelt" <[hidden email]> wrote:

>> Which brings me to the forum question "I've got photos of 13 megapixels that
>> Rev can't handle". Who wants to push the (Revolution) envelope that far ?
>
> Me for one. My app Pic-a-POD <http://www.troz.net/Pic-a-POD/> suffers
> greatly from this problem as more and more large images appear on the
> internet. At the moment I am forced to check for images with more than
> 4000 pixels on any side, and if so, I just have to show a notice
> saying that the image is too big to display. This is not always
> correct as a tall thin image can work but I haven't been able to work
> out an exact algorithm for telling what will work and what won't. Even
> more unfortunately, there is no error reported when Rev tries to
> display an image that is too big - you just get horrible grey streaks
> or some other form of distortion.
>
> As consumer level cameras produce larger and larger images, the
> prevalence of such images will only increase and I think it is
> unrealistic to say that people shouldn't be using such large images.
> If their cameras can do it, why would they not take images at the
> highest possible quality? This is not a problem that is going to go
> away and I think RunRev need to give some serious thought to fixing
> the image object.
>
> Cheers,
> Sarah
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Jim Sims]

On Jun 28, 2009, at 7:07 PM, Mike Markkula wrote:

> I too wish wish wish Rev would remove the 4095 pixel width limit!
> (there is no height limit) As is, its a deal breaker for any serious
> app in the photography arena.

The hindrance extends beyond the scope of photography.

Think of an architect who might need to reference large images, of an  
application which is a tool for people who make tools for developers.  
The list is limited by imagination.

For some issues I wish RunRev would make *patches* available, and  
distribute a fix when a fix becomes available. I can understand  
wanting people to purchase 'assurance packs' but for some fixes a  
patch might gain them more customers and appreciation.

sims

In the incubator now: AppBoot
http://www.ezpzapps.com/AppBoot

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Peter Brigham MD]

This is way outside my area of expertise, but would it be possible to  
kludge up a workaround? It the problem is not importing an image >4095  
wide but displaying it, it should be possible to import it, split it  
into two images <4095 wide by walking through the imagedata, place the  
two side by side, and display them as a group. Nasty, but at least  
allows you to see the image. The problem would be how processor-
intensive and time-consuming would this be. Probably a real limitation.

-- Peter

Peter M. Brigham
[hidden email]
http://home.comcast.net/~pmbrig


On Jun 28, 2009, at 1:07 PM, Mike Markkula wrote:

> Sarah,
>
> The script below will at least treat the user properly.
>
> I too wish wish wish Rev would remove the 4095 pixel width limit!
> (there is no height limit) As is, its a deal breaker for any serious
> app in the photography arena.
>
> Mike Markkula
>
> --------------------------------------------------
> function importImageFile theFilePath
>   -- attempt to create image given its file path
>   -- if successful, return its id,  if not, return empty
>   -- Rev can import images wider than 4095 pixels,
>   -- but can’t display them properly
>
>   set the itemDelimiter to "/"
>   put the last item of theFilePath into theImageName
>
>   try
>      import paint from file theFilePath
>      put the ID of the last image into theImageID
>      if the width of image ID theImageID > 4095 then
>         delete image ID theImageID
>         put empty into theImageID
>         beep
>         answer "Sorry, I can't open " & quote & theImageName & quote  
> & \
>         " because it's wider than 4095 pixels."
>       end if
>   catch anyError
>      if anyError is not empty then
>         delete image ID theImageID
>         put empty into theImageID
>         beep
>         answer "Sorry, I can't import " & quote & theImageName &  
> quote & \
>         " because " & anyError & "."
>      end if
>   end try
>
>   return theImageID
> end importImageFile
> -------------------------------------
>
> On 6/27/09 5:33 PM, "Sarah Reichelt" <[hidden email]> wrote:
>
>>> Which brings me to the forum question "I've got photos of 13  
>>> megapixels that
>>> Rev can't handle". Who wants to push the (Revolution) envelope  
>>> that far ?
>>
>> Me for one. My app Pic-a-POD <http://www.troz.net/Pic-a-POD/> suffers
>> greatly from this problem as more and more large images appear on the
>> internet. At the moment I am forced to check for images with more  
>> than
>> 4000 pixels on any side, and if so, I just have to show a notice
>> saying that the image is too big to display. This is not always
>> correct as a tall thin image can work but I haven't been able to work
>> out an exact algorithm for telling what will work and what won't.  
>> Even
>> more unfortunately, there is no error reported when Rev tries to
>> display an image that is too big - you just get horrible grey streaks
>> or some other form of distortion.
>>
>> As consumer level cameras produce larger and larger images, the
>> prevalence of such images will only increase and I think it is
>> unrealistic to say that people shouldn't be using such large images.
>> If their cameras can do it, why would they not take images at the
>> highest possible quality? This is not a problem that is going to go
>> away and I think RunRev need to give some serious thought to fixing
>> the image object.
>>
>> Cheers,
>> Sarah
>> _______________________________________________
>> use-revolution mailing list
>> [hidden email]
>> Please visit this url to subscribe, unsubscribe and manage your  
>> subscription
>> preferences:
>> http://lists.runrev.com/mailman/listinfo/use-revolution
>>
>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Ben Rubinstein]

If this issue matters to you, please make your views persistent by adding
comments/votes to
  http://quality.runrev.com/qacenter/show_bug.cgi?id=4026

thank you.

Ben

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Richard Gaskin]

Ben Rubinstein wrote:
> If this issue matters to you, please make your views persistent by adding
> comments/votes to
>   http://quality.runrev.com/qacenter/show_bug.cgi?id=4026

Thank you for bringing that to my attention.  I have an app coming up
which will need to process JPEGs from cameras, and if I had to exclude
so very many modern cameras because of this resolution issue the app
would barely be worth shipping.

Sarah's comments there were especially helpful.

Thanks to both of you and the other contributors to that report.

--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Jonathan Lynch-3]

This is an issue for me right now :(

I am thinking about some sort of mosaic approach, in order to effectively get a high enough resolution background image for printing.
------Original Message------
From: Richard Gaskin
Sender: [hidden email]
To: How to use Revolution
ReplyTo: How to use Revolution
Subject: Re: Rev cannot open my jpeg ! - and some serious thinking
Sent: Jun 29, 2009 2:54 PM

Ben Rubinstein wrote:
> If this issue matters to you, please make your views persistent by adding
> comments/votes to
>   http://quality.runrev.com/qacenter/show_bug.cgi?id=4026

Thank you for bringing that to my attention.  I have an app coming up
which will need to process JPEGs from cameras, and if I had to exclude
so very many modern cameras because of this resolution issue the app
would barely be worth shipping.

Sarah's comments there were especially helpful.

Thanks to both of you and the other contributors to that report.

--
  Richard Gaskin
  Fourth World
  Revolution training and consulting: http://www.fourthworld.com
  Webzine for Rev developers: http://www.revjournal.com
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution


Sent from my Verizon Wireless BlackBerry
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Jim Lambert]

> would it be possible to
> kludge up a workaround

If it's just display of big JPEGs you need, how about importing and  
displaying them in a (QT) player?

Jim Lambert
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Jonathan Lynch-3]

My issue is that I am copying and pasting from Photoshop to RunRev. If the
file is too large, RunRev will not recognize that there is an image in the
clipboard.

I plan to tinker with this endlessly, because I really want the picture to
be able to print with 300 DPI resolution. That does not seem like too much
to ask for.

On Mon, Jun 29, 2009 at 4:43 PM, Jim Lambert <[hidden email]> wrote:

>
>  would it be possible to
>> kludge up a workaround
>>
>
> If it's just display of big JPEGs you need, how about importing and
> displaying them in a (QT) player?
>
> Jim Lambert
>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

--
Do all things with love
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Sarah Reichelt-2]

>> Me for one. My app Pic-a-POD <http://www.troz.net/Pic-a-POD/> suffers
>> greatly from this problem as more and more large images appear on the
>> internet. At the moment I am forced to check for images with more than
>> 4000 pixels on any side, and if so, I just have to show a notice
>> saying that the image is too big to display.
>
> +1
>
> Pic-a-POD sits on my desktop :-)
>
> "POD" web sites do change their format from time to time, though...
> For instance, National Geographic leads to a "Picture is not in the
> correct format" warning.
> and Wikipedia furnishes regurlarly too big images!

Just to confirm this after some tests:
- the problem is on Mac only
- the height of the image does not seem to matter
- my test image displayed correctly at 4090 x 3000 pixels (72 dpi)
- my test image sometimes displayed correctly at 4091 x 3000 pixels (72 dpi)
- my test image failed at 4095 x 3000 pixels (72 dpi)

I have not yet done enough testing to tell whether the overall number
of pixels or the dpi alters this slightly variable cut-off point.
For Pic-a-POD, I intend to change "Can't display" message so it only
shows if the width of the image is > 4000 and the platform is Mac.

BTW, Dom there is now an update to Pic-a-POD that fixes the National
Geographic problem.

With regard to Wikipedia supplying enormous images, does anyone know a
method for determining the size of a download before it starts? Once
the download has begun the URLStatus gives the total size, but it
would be really useful to get this before starting. I guess I can see
whether I can get a directory listing but I doubt that would be
permitted. The only other option I can think of is to start
downloading invisibly, and stop after the first status report, suing
that data to see whether the incoming image file is too large.

Cheers,
Sarah
_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Mark Smith]

Sarah, to get the size of what will be returned by a "get url", you  
need to issue an HTTP HEAD request, which will return the http  
headers that would be returned from a GET request, but without the  
actual content. Something like this in a button script:

on mouseUp
    put "http://futsoft.futilism.com/revolutionstuff.html" into tUrl
     put urlHead(tUrl)
end mouseUp

function urlHead pUrl
    set the itemdelimiter to "/"
    put "HEAD /" && item 4 to -1 of pUrl && "HTTP/1.1" & cr into tHeads
    put "Host:" && item 3 of pUrl & cr after tHeads
    put "Accept: */*" after tHeads
    libUrlSetCustomHttpHeaders tHeads
    get url pUrl
    return libUrlLastRhHeaders()
end urlHead

should return something like:

HTTP/1.1 200 OK
Date: Wed, 01 Jul 2009 09:30:23 GMT
Server: Apache
Last-Modified: Sun, 26 Apr 2009 21:55:28 GMT
ETag: "32224e1-19ca-49aab400"
Accept-Ranges: bytes
Content-Length: 6602
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

where the "Content-Length" line is the size in bytes of the content.

Sometimes this seems to take quite a few seconds, and I don't know  
why (I think libUrl doesn't like non-GET/POST requests), but if you  
have curl available, you can do this:

get shell("curl -s -I " && quote & tUrl & quote) -- that '-I'  is an  
uppercase 'I' for India
which will give you the same thing, without any delay.

Best,

Mark


On 1 Jul 2009, at 09:07, Sarah Reichelt wrote:

> With regard to Wikipedia supplying enormous images, does anyone know a
> method for determining the size of a download before it starts? Once
> the download has begun the URLStatus gives the total size, but it
> would be really useful to get this before starting. I guess I can see
> whether I can get a directory listing but I doubt that would be
> permitted. The only other option I can think of is to start
> downloading invisibly, and stop after the first status report, suing
> that data to see whether the incoming image file is too large.

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Mark Smith]

In fact, I'd recommend the curl method, as it seems like the libUrl  
method doesn't seem to get all the headers, anyway.

For this url: "http://marksmith.on-rev.com/msbass/instruments.html"
the liburl method got:

HTTP/1.1 200 OK
Date: Wed, 01 Jul 2009 09:46:17 GMT
Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5  
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Connection: close
Content-Type: text/html;charset=ISO-8859-1

whereas the curl method got:

HTTP/1.1 200 OK
Date: Wed, 01 Jul 2009 09:49:05 GMT
Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-rhel5  
mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
Last-Modified: Fri, 17 Apr 2009 14:22:33 GMT
ETag: "c0c0087-2150-e956bc40"
Accept-Ranges: bytes
Content-Length: 8528
Content-Type: text/html

Dave (Cragg) - is there a better way to do a HEAD request using libUrl?

Best,

Mark


On 1 Jul 2009, at 10:42, Mark Smith wrote:

> Sometimes this seems to take quite a few seconds, and I don't know  
> why (I think libUrl doesn't like non-GET/POST requests), but if you  
> have curl available,

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Ian Wood-3]

Pixel size is needed for getting around this bug, not file size...

Ian

On 1 Jul 2009, at 10:42, Mark Smith wrote:

> Sarah, to get the size of what will be returned by a "get url", you  
> need to issue an HTTP HEAD request, which will return the http  
> headers that would be returned from a GET request, but without the  
> actual content. Something like this in a button script:

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Mark Smith]

I see what you mean, if the height doesn't matter. Perhaps one could  
apply some sort of guess about what height/width ratios are likely/
unlikely, and go from there?

Best,

Mark

On 1 Jul 2009, at 11:00, Ian Wood wrote:

> Pixel size is needed for getting around this bug, not file size...
>
> Ian
>
> On 1 Jul 2009, at 10:42, Mark Smith wrote:
>
>> Sarah, to get the size of what will be returned by a "get url",  
>> you need to issue an HTTP HEAD request, which will return the http  
>> headers that would be returned from a GET request, but without the  
>> actual content. Something like this in a button script:
>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your  
> subscription preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Sarah Reichelt-2]

Sorry, I side-tracked the thread into helping me work out the size of
a download,rather than the pixels of an image.

Sarah


On Wed, Jul 1, 2009 at 8:00 PM, Ian Wood<[hidden email]> wrote:

> Pixel size is needed for getting around this bug, not file size...
>
> Ian
>
> On 1 Jul 2009, at 10:42, Mark Smith wrote:
>
>> Sarah, to get the size of what will be returned by a "get url", you need
>> to issue an HTTP HEAD request, which will return the http headers that would
>> be returned from a GET request, but without the actual content. Something
>> like this in a button script:
>
> _______________________________________________
> use-revolution mailing list
> [hidden email]
> Please visit this url to subscribe, unsubscribe and manage your subscription
> preferences:
> http://lists.runrev.com/mailman/listinfo/use-revolution
>

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution

[Dave Cragg-2]

On 1 Jul 2009, at 10:50, Mark Smith wrote:

> In fact, I'd recommend the curl method, as it seems like the libUrl  
> method doesn't seem to get all the headers, anyway.
>
> For this url: "http://marksmith.on-rev.com/msbass/instruments.html"
> the liburl method got:
>
> HTTP/1.1 200 OK
> Date: Wed, 01 Jul 2009 09:46:17 GMT
> Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-
> rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
> Connection: close
> Content-Type: text/html;charset=ISO-8859-1
>
> whereas the curl method got:
>
> HTTP/1.1 200 OK
> Date: Wed, 01 Jul 2009 09:49:05 GMT
> Server: Apache/2.0.63 (Unix) mod_ssl/2.0.63 OpenSSL/0.9.8e-fips-
> rhel5 mod_auth_passthrough/2.1 mod_bwlimited/1.4 FrontPage/5.0.2.2635
> Last-Modified: Fri, 17 Apr 2009 14:22:33 GMT
> ETag: "c0c0087-2150-e956bc40"
> Accept-Ranges: bytes
> Content-Length: 8528
> Content-Type: text/html
>
> Dave (Cragg) - is there a better way to do a HEAD request using  
> libUrl?

I tried your method (urlHead function) and it returned a full set of  
headers:

HTTP/1.1 200 OK
Date: Wed, 01 Jul 2009 11:35:42 GMT
Server: Apache
Last-Modified: Sun, 26 Apr 2009 21:55:28 GMT
ETag: "32224e1-19ca-49aab400"
Accept-Ranges: bytes
Content-Length: 6602
Vary: Accept-Encoding
Connection: close
Content-Type: text/html

Just a couple of points about the function. You should probably add a  
"Connection: close" header. In this case it didn't matter as the  
server closed the connection anyway. But with other servers, it may  
cause a timeout as libUrl thinks it's handling a GET request and will  
try to read from the socket while it is open.

You should perhaps also set libUrlFollowHttpRedirects to false. This  
isn't so clean as you can't get the current state of the redirect  
setting, and restore it later.

And unlike other libUrl calls, you should ignore "the result" on this.  
It will always indicate an error.

Things would be better if HEAD were handled properly so we didn't have  
to use workarounds such as these.

Cheers
Dave

_______________________________________________
use-revolution mailing list
[hidden email]
Please visit this url to subscribe, unsubscribe and manage your subscription preferences:
http://lists.runrev.com/mailman/listinfo/use-revolution