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

[Sarah Reichelt-2]

On Wed, Jul 1, 2009 at 7:42 PM, Mark Smith<[hidden email]> 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:
>
snip
>
> 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.

Thanks very much for this Mark.

I tried the UrlHead method first, but got only "Bad request".
It worked fine for your html page, but trying on a php page or on an
image file gave the bad request, although I can't tell if this is
server-dependent, or related to the file types.
I have tested Dave Cragg's suggested modifications and they made no difference.

The curl method works beautifully on my Mac, but is curl available on
Windows computers?

However I have now realised that Wikipedia includes the image file
size in it's web page, so I can search for it there before downloading
- it just isn't as slick as it relies on their formating no changing.

If anyone has any further suggestions, I would love to try them.

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, curl is certainly available for windows, but AFAIK is not part  
of the standard installation - it can be found here:

http://curl.haxx.se/download.html


Best,

Mark



On 2 Jul 2009, at 02:10, Sarah Reichelt wrote:

> The curl method works beautifully on my Mac, but is curl available on
> Windows computers?

_______________________________________________
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 Ault]

I don't seem to be able to make the easy connections between Macs  
running OSX 10.5 using Alex Tweedly's companion stacks
UDP Echo Client
UDP Echo Server

I have set the fire wall in OSX to 'allow all incoming connections',
both computers have a static IP address,
are connected to the internet using a switch (not a router)

but UDP traffic between them does not test positive.
This has not been a problem in the past using OSX 10.4 (Tiger)

[1]
compiled - UDP Echo Client running as an app on computer B
UDP Echo Server in Rev 2.7.2 on computer A

[2]
compiled - UDP Echo Client running as an app on computer B
UDP Echo Server in Rev 2.9.0 on computer A

Can anyone shed some light on how to make this work?

Thanks,

Jim Ault
Las Vegas
_______________________________________________
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

[Alex Tweedly]

Jim Ault wrote:

Jim - I could preface each part of my reply with .... "Sorry I don't
have a Mac w/ Leopard to check,"
> I don't seem to be able to make the easy connections between Macs
> running OSX 10.5 using Alex Tweedly's companion stacks
> UDP Echo Client
> UDP Echo Server
>
> I have set the fire wall in OSX to 'allow all incoming connections',
...check, but I wouldn't be surprised if that meant "allow incoming TCP
connections", and there might be a separate setting for UDP.
> both computers have a static IP address,
> are connected to the internet using a switch (not a router)
>
No, I don't believe that. (Almost) no-one is connected to the Internet
without a router - it's just a question of where the router is. Do you
mean that the computers are both connected to a switch - and behind that
is the router and Internet connection ? And therefore the two should be
communicating locally ?

> but UDP traffic between them does not test positive.
> This has not been a problem in the past using OSX 10.4 (Tiger)
>
> [1]
> compiled - UDP Echo Client running as an app on computer B
> UDP Echo Server in Rev 2.7.2 on computer A
>
> [2]
> compiled - UDP Echo Client running as an app on computer B
> UDP Echo Server in Rev 2.9.0 on computer A
>

Do you still have 10.4 systems around so you can try client on 10.4 and
server on 10.5, etc. ?
> Can anyone shed some light on how to make this work?
Stupid question - does it work with client and server on the same computer ?
Are they on the same subnet ?
Can you do a ping from one to the other ?
How about a traceroute - just to check there is a direct connection ?
If you clear the arp cache, then run the client, does the sever then
show up in the arp cache ?
   (in a terminal window - "arp -a" to see the cache, "arp -d -a" to
clear it)


I'll try to find a Leopard system tomorrow to play with it ....

-- Alex.
_______________________________________________
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

[Jerry J]

On Jun 28, 2009, at 10:07 AM, Mike Markkula wrote:

> Sarah,
>
> 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.

I've been looking into the problem with images wider than 4091 pixels  
on OS X.

A while ago, Devin Asay suggested that one could load the image, then  
split the imagedata before displaying it in sections. Mike Markkula  
wrote a nice stack to do just that, but asked for my help when it  
didn't work quite correctly, for no apparent reason.

The problem is worse than we thought. A wide image imports without  
reporting errors, but the imagedata is messed up before you can get to  
it. Its very odd. If an image is 4091 wide, everything seems fine. If  
an image is wider than that, the imagedata is wrong starting with  
pixel #4048 (!). What a strange number!

The scary part is that the messed up bytes came from somewhere wrong.  
We don't know where they came from. Its unlikely that they would be  
outside of Rev's app space (page fault) but it could be dangerous to  
_write_ to those locations by exporting the image by whatever means.

I made an ugly little stack to view the raw pixels of an image. Its at:
http://www.jhj.com/WideBug.zip
  with some test images that have consistent RGB values. Note that  
pixel 4047 is OK, 4048 is not. 4100 (last of first row) is not, and  
different. In each example, the last row appears to be correct. I  
haven't looked deeper, I've seen enough.

It doesn't matter how you load the image - there is a button each for  
the three methods I know about - all give the same results.

Beware! Vote for bug # 4026 !!
http://quality.runrev.com/qacenter/show_bug.cgi?id=4026

Jerry Jensen

_______________________________________________
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 Ault]

Short answer:  Rev 2.7.2  works   and   2.9.0 does not  (on both the  
same subnet and static IP configuration)
I don't own 3.+ so I cannot test this version.

UDP on OSX Tiger listens using 2.7.2
TCP on OSX Tiger listens using 2.7.2

UDP on OSX Leopard listens using 2.7.2  **not
UDP on OSX Leopard listens using 2.9.0  **not

TCP on OSX Leopard listens using 2.7.2
TCP on OSX Leopard listens using 2.9.0  **not

TCP on OSX Leopard listens using stand alone compiled with 2.7.2
TCP on OSX Leopard listens using stand alone compiled with 2.9.0  **not


On Jul 7, 2009, at 5:05 PM, Alex Tweedly wrote:

> Jim Ault wrote:
>
> Jim - I could preface each part of my reply with .... "Sorry I don't  
> have a Mac w/ Leopard to check,"
>> I don't seem to be able to make the easy connections between Macs  
>> running OSX 10.5 using Alex Tweedly's companion stacks
>> UDP Echo Client
>> UDP Echo Server
>>
>> I have set the fire wall in OSX to 'allow all incoming connections',
> ...check, but I wouldn't be surprised if that meant "allow incoming  
> TCP connections", and there might be a separate setting for UDP.
>> both computers have a static IP address,
>> are connected to the internet using a switch (not a router)
>>
> No, I don't believe that. (Almost) no-one is connected to the  
> Internet without a router - it's just a question of where the router  
> is. Do you mean that the computers are both connected to a switch -  
> and behind that is the router and Internet connection ? And  
> therefore the two should be communicating locally ?

Cable modem > switch> (2) computers with static IP addresses in same  
subnet 255.255.255.224

>> but UDP traffic between them does not test positive.
>> This has not been a problem in the past using OSX 10.4 (Tiger)
>>
>> [1]
>> compiled - UDP Echo Client running as an app on computer B
>> UDP Echo Server in Rev 2.7.2 on computer A
>>
>> [2]
>> compiled - UDP Echo Client running as an app on computer B
>> UDP Echo Server in Rev 2.9.0 on computer A
>>
> Do you still have 10.4 systems around so you can try client on 10.4  
> and server on 10.5, etc. ?

only on one system which I will try tonight as a third cpu on the same  
wireless router

>> Can anyone shed some light on how to make this work?
> Stupid question - does it work with client and server on the same  
> computer ?
localhost  or 127.0.0.1  works as expected

> Are they on the same subnet ?
subnet mask is the same   255.255.255.224
> Can you do a ping from one to the other ?
Screen Sharing works, so does FTP in both directions.
In fact I use screen sharing to operate the Mac mini running the app.

> How about a traceroute - just to check there is a direct connection ?
> If you clear the arp cache, then run the client, does the sever then  
> show up in the arp cache ?
>  (in a terminal window - "arp -a" to see the cache, "arp -d -a" to  
> clear it)
>

> I'll try to find a Leopard system tomorrow to play with it ....
>
> -- Alex.
> _______________________________________________
> 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 Ault
[hidden email]


_______________________________________________
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 Ault]

Would calling shell commands on Leopard be a good test of Rev using  
UDP ?
Rev 2.7.2 does TCP on Leopard, not UDP
Rev 2.9.0 does not do UDP on Leopard for 127.0.0.1 (localhost)

If the shell commands using Terminal don't work properly, then it  
would not be a Rev problem.
Just a thought

Jim Ault
Las Vegas


On Jul 7, 2009, at 5:05 PM, Alex Tweedly wrote:

> Jim Ault wrote:
>
> Jim - I could preface each part of my reply with .... "Sorry I don't  
> have a Mac w/ Leopard to check,"
>> I don't seem to be able to make the easy connections between Macs  
>> running OSX 10.5 using Alex Tweedly's companion stacks
>> UDP Echo Client
>> UDP Echo Server
>>
>> I have set the fire wall in OSX to 'allow all incoming connections',
> ...check, but I wouldn't be surprised if that meant "allow incoming  
> TCP connections", and there might be a separate setting for UDP.
>> both computers have a static IP address,
>> are connected to the internet using a switch (not a router)
>>
> No, I don't believe that. (Almost) no-one is connected to the  
> Internet without a router - it's just a question of where the router  
> is. Do you mean that the computers are both connected to a switch -  
> and behind that is the router and Internet connection ? And  
> therefore the two should be communicating locally ?
>> but UDP traffic between them does not test positive.
>> This has not been a problem in the past using OSX 10.4 (Tiger)
>>
>> [1]
>> compiled - UDP Echo Client running as an app on computer B
>> UDP Echo Server in Rev 2.7.2 on computer A
>>
>> [2]
>> compiled - UDP Echo Client running as an app on computer B
>> UDP Echo Server in Rev 2.9.0 on computer A
>>
> Do you still have 10.4 systems around so you can try client on 10.4  
> and server on 10.5, etc. ?
>> Can anyone shed some light on how to make this work?
> Stupid question - does it work with client and server on the same  
> computer ?
> Are they on the same subnet ?
> Can you do a ping from one to the other ?
> How about a traceroute - just to check there is a direct connection ?
> If you clear the arp cache, then run the client, does the sever then  
> show up in the arp cache ?
>  (in a terminal window - "arp -a" to see the cache, "arp -d -a" to  
> clear it)
>
>
> I'll try to find a Leopard system tomorrow to play with it ....
>
> -- Alex.

_______________________________________________
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, and anyone else wanting to use image files wider than 4091 pixels,

Here's a partial work around for working with files larger than 4091 pixels
wide. It's based in part on Devin Asay's idea of splitting the imageData
into pieces small enough for rev to handle & then displaying them side by
side. As it turns out, that won't work because rev corrupts all the pixels
in each row from 4047 to the end of the row, so even though you can read
image files of any width, only the first 4047 pixels of each row are usable.
With the help of my trusty sidekick Jerry Jensen, I wrote an example stack
that loads images wider than 4091 and creates a useful image object from the
first 4047 pixels of each row. For some applications it may be better than
no image at all... Here's a link to download the example stack:
http://acm.on-rev.com/WideImagePartialWorkAround.rev.zip

This is definitely a problem that rev needs to fix very soon!
Vote for bug # 4026 !!
http://quality.runrev.com/qacenter/show_bug.cgi?id=4026

Go Rev!

Mike Markkula

On 7/1/09 1:07 AM, "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!
>
> 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
>

_______________________________________________
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]

On Tue, Jul 14, 2009 at 9:39 AM, Mike Markkula<[hidden email]> wrote:

> Sarah, and anyone else wanting to use image files wider than 4091 pixels,
>
> Here's a partial work around for working with files larger than 4091 pixels
> wide. It's based in part on Devin Asay's idea of splitting the imageData
> into pieces small enough for rev to handle & then displaying them side by
> side. As it turns out, that won't work because rev corrupts all the pixels
> in each row from 4047 to the end of the row, so even though you can read
> image files of any width, only the first 4047 pixels of each row are usable.
> With the help of my trusty sidekick Jerry Jensen, I wrote an example stack
> that loads images wider than 4091 and creates a useful image object from the
> first 4047 pixels of each row. For some applications it may be better than
> no image at all... Here's a link to download the example stack:
> http://acm.on-rev.com/WideImagePartialWorkAround.rev.zip

Thanks for this Mark & Jerry. I very clever solution and in some
cases, it will definitely be the better option.
In my current project, I don't think I can expect users to wait that
long while the image is resized, so I just say I can't show it and
offer them other ways to view.

I have realised that I can use a player object to display large
images. What are the disadvantages to switching to using players
instead of images?

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

[Jim Ault]

UDP *does indeed* work as expected on Mac OSX 10.5

My client situation was complicated by the un-manned data center  
configuration of multiple firewalls, multiple Mac mini computers and a  
few settings that were incorrect.

I did not have admin access to the physical firewalls and these  
settings caused a few errors that were hard to trace.
Added to this was a few special filters I programmed in to the test  
loops for the UDP Echo Client and Echo Server.
The tracing steps made assumptions that later became known to be false.
After the technician in the data center set all ports correctly, every  
test became valid.

Most all testing was done on remote computers
TCP always worked.
UDP only worked in a few cases.
The test software was not reset to the default (my error) and added  
more dis-information to the mix.

I will report back in a week or so to confirm success for all  
combinations of ...
TCP  and UDP ...
Rev  2.7.2   2.9.0   and   3.5   running on ...
Mac OSX 10.5  +  Win Server 2003  +  XP Pro + XP Home Edition ...
both remote and local

I will leave the Win ME testing to those who enjoy leaping off of tall  
structures with minimal padding.

Thanks to Alex Tweedly and Jim Sims for help and support.
(Jim Sims spoke with me using Skype and tried to help with Rev 3.5,  
very cool)
I will even try a little packet-speed testing between Las Vegas and  
Malta, if Jim has the time.

It feels really good to have the speed of UDP as part of my tool box  
again !!
Jim Ault
Las Vegas


On Jul 7, 2009, at 5:05 PM, Alex Tweedly wrote:

> Jim Ault wrote:
>
> Jim - I could preface each part of my reply with .... "Sorry I don't  
> have a Mac w/ Leopard to check,"
>> I don't seem to be able to make the easy connections between Macs  
>> running OSX 10.5 using Alex Tweedly's companion stacks
>> UDP Echo Client
>> UDP Echo Server
>>
>> I have set the fire wall in OSX to 'allow all incoming connections',
> ...check, but I wouldn't be surprised if that meant "allow incoming  
> TCP connections", and there might be a separate setting for UDP.
>> both computers have a static IP address,
>> are connected to the internet using a switch (not a router)
>>
> No, I don't believe that. (Almost) no-one is connected to the  
> Internet without a router - it's just a question of where the router  
> is. Do you mean that the computers are both connected to a switch -  
> and behind that is the router and Internet connection ? And  
> therefore the two should be communicating locally ?
>> but UDP traffic between them does not test positive.
>> This has not been a problem in the past using OSX 10.4 (Tiger)
>>
>> [1]
>> compiled - UDP Echo Client running as an app on computer B
>> UDP Echo Server in Rev 2.7.2 on computer A
>>
>> [2]
>> compiled - UDP Echo Client running as an app on computer B
>> UDP Echo Server in Rev 2.9.0 on computer A
>>
> Do you still have 10.4 systems around so you can try client on 10.4  
> and server on 10.5, etc. ?
>> Can anyone shed some light on how to make this work?
> Stupid question - does it work with client and server on the same  
> computer ?
> Are they on the same subnet ?
> Can you do a ping from one to the other ?
> How about a traceroute - just to check there is a direct connection ?
> If you clear the arp cache, then run the client, does the sever then  
> show up in the arp cache ?
>  (in a terminal window - "arp -a" to see the cache, "arp -d -a" to  
> clear it)
>
>
> I'll try to find a Leopard system tomorrow to play with it ....

Jim Ault
[hidden email]


_______________________________________________
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